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Foreword 


This  guideline  is  designed  to  assist  Individuals  In 
writing  FORTRAN  programs.  Adherence  to  the  conventions 
described  herein  should  lead  to  readable  and  maintain¬ 
able  programs.  In  addition,  it  should  significantly 
reduce  the  amount  of  time  and  effort  required  to 
transfer  a  program  from  one  computer  to  another.  Al¬ 
though  this  document  was  written  to  serve  as  a  coding 
guideline,  which  the  Acoustic  Modeling  Manager  of  the 
Surveillance  Environmental  Acoustic  Support  (SEAS) 
Project  could  provide  to  contractors  and  other  Navy 
organizations  supporting  the  SEAS  effort,  It  could 
also  be  used,  without  modification,  by  any  organiza¬ 
tion  writing,  or  contracting  for,  FORTRAN  programs. 

^ 

G.T.  PHELPS,  Captain,  USN 
Commanding  Officer,  NOROA 
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Guidelines  for  Coding  FORTRAN  Programs 


1.  Introduction 

) .  1  Scope 

This  document  provides  a  set  of  conven¬ 
tions  to  be  followed  when  writing 
FORTRAN  programs.  Adherence  to  these 
guidelines  should  make  it  easier  for 
programmers  to  understand  the  programs 
they  write,  especially  when  they  review 
them  three  weeks,  three  months,  or 
three  years  after  their  inception. 

This  increased  understanding  will  also 
allow  developers  to  concentrate  on 
solving  the  problems  that  their  pro¬ 
grams  were  originally  designed  to 
address,  rather  than  resolving  the 
problems  created  by  programming  in  an 
arbitrary,  undisciplined  style. 
Adherence  to  these  guidelines  should 
make  program  maintenance  less  time- 
consuming  for  the  individual,  and  less 
expensive  for  the  organization 
chartered  with  this  responsibility. 
Adherence  to  these  guidelines  should 
also  facilitate  transferring  a  program 
fran  one  computer  to  another. 

Most  of  the  conventions  contained  here 
are  concrete  and  specific  to  facilitate 
enforcement . 

This  document  assumes  that  the  reader 
is  conversant  in  FORTRAN,  and  thus  does 
not  attempt  to  explain  the  purpose  or 
the  meaning  of  FORTRAN  statements  and 
associated  constructs.  Readers  inter¬ 
ested  in  achieving  a  better  understand¬ 
ing  of  the  syntax  and  semantics  of  the 
FORTRAN  statements  mentioned  herein  are 
referred  to  the  books  by  McCracken 
(1972a)  and  Control  Data  Corporation 
(1976)  mentioned  in  the  reference 
section  of  this  report. 

The  American  Standards  Institute  (ANSI) 
USA  Standard  FORTRAN  X3. 9-1966  was  used 
as  a  starting  point  in  writing  this 


document.  Photocopies  of  this  standard 
may  be  purchased  from  the  American 
National  Standards  Institute,  Inc., 

1430  Broadway,  New  York,  NY  10018 
(Telephone:  (212)  354-3300).  At  the 
time  of  writing,  X3. 9-1966  cost  $24.95, 
and  X3. 9-1978  cost  $16.50,  with  a  $4.00 
shipping  charge.  USA  Standard  Basic 
FORTRAN  X3. 10-1966  was  not  used  because 
most  programs  for  the  underwater  acous¬ 
tics  community  do  not  run  on  the  small 
systems  for  which  this  standard  was 
designed.  Although  a  more  recent  FOR¬ 
TRAN  standard  (ANSI  Standard  X3. 9-1978, 
sometimes  referred  to  as  FORTRAN  77) 
exists,  we  have  chosen  not  to  use  it 
because  many  FORTRAN  compilers  in  the 
Navy  do  not  support  it,  even  though  it 
was  declared  the  approved  standard  on  3 
Apr  78  and  X3. 9-1966  was  withdrawn.  The 
new  FORTRAN  Standard  was  designed,  how¬ 
ever,  to  minimize  conflicts  with  X3.9- 
1966.  We  have  modified  this  report  to 
further  reduce  these  conflicts.  Unfor¬ 
tunately,  adherence  to  these  standaids 
does  not  guarante '  that  programs  will 
be  written  clearly  or  concisely,  or 
will  have  a  well-structured  design.  And 
X3. 9-1966  does  not  permit  many  desira¬ 
ble  FORTRAN  constructs,  such  as  speci¬ 
fication  of  Hollerith  characters  with¬ 
out  character  counts.  To  achieve  maxi¬ 
mum  transferability  of  software, 
developers  must  consider  other  factors 
not  addressed  by  the  standard,  and  even 
avoid  the  use  of  some  statements  per¬ 
mitted  by  the  standard.  Because  many 
programmers  may  not  be  exactly  sure 
what  is,  or  what  is  not,  permitted  by 
the  ANSI  standard,  this  document  com¬ 
ments  on  many  commonly  used  constructs 
which  are  not  permitted  by  the  stand¬ 
ard,  and  specifically  states  when  they 
must  be  avoided. 

This  document  was  developed  by  consid¬ 
ering  coding  conventions  suggested  in 
the  works  of  Berkowitz  (1976),  Fleiss 
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(1974),  Jacobs  (1976),  Ledgard  (1978), 
McCracken  (1972a  and  1972b),  Roberts 
(1969),  Jensen  (1979)  and  Yourdon 
(1975),  as  well  as  the  author's  pro¬ 
gramming  experience.  At  times,  it  was 
necessary  to  choose  between  conventions 
that  appeared  to  have  equal  merits,  but 
which  were  either  conflicting  or  incon¬ 
sistent  with  one  another. 

For  ease  of  reference,  the  guidelines 
have  been  arranged  in  the  order  that 
the  subjects  would  normally  be  covered 
in  a  FORTRAN  reference  manual.  Pre¬ 
ceding  each  coding  convention  described 
in  this  document  is  a  letter:  M,  S, 
or  L.  An  M  next  to  a  convention  indi¬ 
cates  that  it  must,  in  the  author's 
opinion,  always  be  followed.  Any  vio¬ 
lations  of  such  a  convention  must  be 
approved  by  the  individual  in  the 
organization  who  is  responsible  for 
enforcing  the  coding  guidelines.  An  S 
indicates  the  coding  convention  should 
be  followed  whenever  possible.  An  L 
indicates  that  it  would  be  helpful  to 
follow  this  convention  because  it  most 
likely  would  improve  program  clarity. 

Section  11  provides  a  summary  of  the 
possible  FORTRAN  statements,  indicates 
the  sections  of  this  document  where 
they  are  discussed,  and  offers  overall 
recommendations  concerning  their  use. 

Section  12  is  divided  into  two  parts. 
The  first  part  shows  the  original 
coding  of  an  ambient  noise  model 
(CNOISE).  This  code  was  written  prior 
to  the  formulation  of  the  guidelines 
suggested  herein  and  is  an  actual 
model,  rather  than  an  example  designed 
exclusively  for  this  report.  It  is 
typical  and,  in  many  respects,  better 
than  most  of  the  coding  found  today. 

Its  major  deficiency  is  the  general 
lack  of  comments.  The  second  part 
shows  this  same  program  after  being 
revised  to  abide  by  the  guidelines 
described  herein. 

Appendix  D  describes  in  detail  how  to 
emulate  the  control  structures  of 
structured  programming  (Jensen  (1979), 
Yourdon  (1975)).  Exclusive  use  of 
these  structures  is  highly  recommended. 


Their  value  has  been  well-established 
by  the  software  engineering  community. 

This  document  was  designed  to  serve  as 
a  guideline  to  be  followed  by  private 
contractors  and  other  organizations 
when  writing  FORTRAN  programs  in  sup¬ 
port  of  the  SEAS  Project  Office.  The 
need  for  this  document  was  clearly 
indicated  by  the  lack  of  attention  many 
software  developers  gave  to  the  clar¬ 
ity,  transportability,  and  maintain¬ 
ability  of  their  progams.  This  neglect 
needlessly  resulted  in  high  program 
conversion  costs,  numerous  maintenance 
headaches,  and  untold  hours  of  wasted 
time  trying  to  decipher  the  meaning  of 
uncommented,  spaghetti-like  logic. 

Since  other  organizations  have  similar 
problems,  it  is  hoped  that  this  docu¬ 
ment  will  prove  to  be  useful  to  them  as 
well.  It  is  believed  that  even  a 
casual  reading  of  this  document  will 
improve  most  programmers'  style. 

2.  Coding  Fortran  Statements 

2.1  General  Remarks  and  Suggestions 

M  -  All  source  code  must  (whenever 

possible)  be  written  in  a  subset  of 
American  National  Standards  Insti¬ 
tute  (ANSI)  FORTRAN,  as  described 
in  X3. 9-1966.  The  limits  of  this 
subset  are  defined  below. 

M  -  Extensions  to  the  above  standard 
must  not  be  used,  unless  implemen¬ 
tation  of  the  program  is  impossible 
without  their  use.  (Some  manufac¬ 
turers,  e.g.,  Control  Data  Corpora¬ 
tion,  have  compilers  that  will 
check  for  and  flag  noncompliance 
with  the  ANSI  standard.) 

M  -  If  the  conventions  described  herein 
are  adopted  as  standards  by  an 
organization,  any  violation  of 
those  conventions  designated  by  the 
letter  M  must  be  approved  by  the 
individual  appointed  to  enforce 
them.  Standards  that  are  not 
enforced  are  useless. 

M  -  Don't  subvert  the  intended  purpose 
of  the  language,  i.e.,  avoid  pro¬ 
gramming  tricks. 


M  -  Do  not  write  programs  that  modify 
themselves  as  they  execute. 

S  -  For  each  installation  and  applica¬ 
tion,  users  should  follow  an 
adopted  set  of  standard  variable 
names.  This  procedure  will  make 
programs  easier  to  understand  and 
interface,  if  required,  at  a  later 
time. 

S  -  Build  as  many  error  checks  iflto  the 
program  as  possible,  under  the 
assumption  that  it  will  do  some¬ 
thing  incorrectly.  This  will  help 
reduce  debugging  time. 

S  -  Avoid  having  one  module  (group  of 
statements  that  perform  a  specific 
function)  "fall”  into  another.  It 
is  better  to  have  explicit 
transfers  between  modules  than  to 
rely  upon  the  sequential  execution 
of  code. 

S  -  Adopt  the  KISS  (Keep  It  Simple, 

Stupid)  philosophy.  Always  use  the 
simplest  language  features  that 
will  solve  the  problem  adequately. 

S  -  Design  the  program  listing  so  that 
it  is  pleasing  to  the  eye. 

S  -  Avoid  including  more  significant 
digits  in  the  output  of  a  program 
than  can  be  justified  by  its 
input . 


2.3  FORTRAN  Statements 

M  -  10RTRAN  keywords  must  be  clearly 
set  off  by  a  blank  character  or 
other  separator  to  improve  program 
clarity. 

M  -  The  executable  statements  in  the 

range  of  a  DO  loop  must  be  indented 
at  least  three  spaces  from  the  DO 
statement  and  terminating  CONTINUE 
statement . 

S  -  FORTRAN  statements  should  be 

numbered  in  columns  73-80.  This 
facilitates  communication  of 
updates  and  reconstruction  of 
dropped  decks. 

S  -  All  elements  related  to  a  specific 
level  of  the  control  structure 
should  be  aligned  to  the  same 
column . 

S  -  All  dependent  processes  associated 
with  a  structure  should  be  indented 
by  a  fixed  amount,  usually  two  to 
five  spaces.  The  optimum  amount  is 
three  spaces.  The  dependent  proc¬ 
ess  could  also  be  a  control  struc¬ 
ture,  in  vrtiich  case  processes  sub¬ 
ordinate  to  the  dependent  control 
structure  should  again  be  indented 
to  indicate  their  relative  position 
in  the  structure. 

2.4  Continuation  Lines 


2.2  FORTRAN  Character  Set 
M  -  Do  not  use  characters  other  than: 


»  equal  sign 
+  plus  sign 
*  asterisk 
/  slash 

(  left  parenthesis 
alphabetic  (A-Z) 

'  apostrophe 


)  right  parenthesis 
,  comma 

.  decimal  point 
-  minus  sign 
blank 

numeric  (0  to  9) 


Only  these  characters  are  permitted  by 
the  ANSI  standard  X3. 9-1978.  The  quote 
(")  and  not-equal  (j*)  symbols  are  not 
permitted.  The  currency  symbol  ($) 
was  permitted  by  X3. 9-1966  but  the 
apostrophe  (’)  was  not. 


M  -  Do  not  use  more  than  nine  (9)  suc¬ 
cessive  continuation  lines.  Nine¬ 
teen  is  the  maximum  permitted  by 
the  ANSI  standards  3.9-1966  and 
X3. 9-1978.  But  the  subset  language 
of  X3. 9-1978  permits  only  nine. 

M  -  Continuation  lines  must  be  desig¬ 
nated  by  nonzero  alphanumeric  char¬ 
acters  in  column  6.  They  must  be 
numbered  sequentially,  starting 
with  1  through  9,  then,  if  needed, 
go  A  through  K.  Column  7  of  a 
continuation  line  must  always  be 
left  blank,  except  when  this  pre¬ 
vents  outputting  a  Hollerith  string 
begun  on  the  previous  line.  This 
step  is  especially  important  in 
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FORMAT  statements,  since  the  inte¬ 
gers  In  column  6  could  be  adjacent 
to  Integers  in  format  fields, 
thereby  reducing  readability.  For 
example,  25X  where  the  2  is  in 
column  6  might  be  incorrectly 
interpreted  as  "skip  25  blanks." 

M  -  Columns  1-5  of  a  continuation  line 
must  contain  blanks.  This  step  is 
included  to  increase  agreement  with 
X3. 9-1978. 

2.5  Statement  Separator 

M  -  Do  not  put  more  than  one  statement 
on  a  line.  Use  of  more  than  one 
statement  per  line  can  make  pro¬ 
grams  extremely  difficult  to  read. 
Also,  it  is  not  permitted  by  the 
ANSI  standard. 

2.6  Statement  Labels 

M  -  Statement  labels  (numbers)  on 
statements  (other  than  FORMAT 
statements)  which  are  not  trans¬ 
ferred  to  from  other  points  in  the 
program  must  be  eliminated  from  the 
source  code.  Extraneous  labels 
make  programs  difficult  to  read  and 
debug . 

M  -  Assign  statement  numbers  in  ascend¬ 
ing  sequence  of  value,  initially  by 
10's  or  100's,  so  that  additional 
statements  can  be  inserted  without 
renumbering. 

M  -  Statement-label  numbers  must  appear 
only  on  CONTINUE  and  FORMAT  state¬ 
ments;  e.g., 

100  CONTINUE 

B  -  SQRT(A-K:) 

not 

100  B  -  SQRT(A-Kl) 

M  -  Do  not  put  a  statement  number  on  an 
END  statement.  Its  use  on  an  END 
statement  is  not  permitted  by  ANSI 
standard  FORTRAN. 

M  -  The  statement  labels  used  in  a  con¬ 
trol  statement  must  be  associated 
with  executable  statements  within 


the  same  program  unit  in  vtoich  the 
control  statement  appears. 

S  -  Keep  statement  numbers  from  one  to 
four  digits  in  length.  Although 
ANSI  X3. 9-1966  FORTRAN  permits  up 
to  five  digits,  four  digits  seems 
adequate  and  helps  to  prevent 
errors  due  to  digits  accidentally 
being  typed  in  column  6. 

L  -  Make  all  FORMAT  statement  numbers 
begin  with  the  digit  9  and  total 
four  digits. 

L  -  Statement-label  numbers  should  be 
left  justified  in  columns  2  through 
5.  This  will  help  to  prevent 
errors  that  can  occur  when  one  of 
the  digits  is  accidentally  punched 
in  column  6-  Also  by  starting  in 
column  2,  the  first  digit  stands 
out  more  clearly  than  if  the  number 
started  in  column  1,  since  often 
there  are  comment  cards,  with  Cs  in 
column  1  before  and  after  this 
card . 

2.7  Comments  (Also  see  Sect.  8.1) 

M  -  All  comment  cards  must  begin  with  C 
in  column  1.  Other  comment  indica¬ 
tors,  such  as  /,  *,  and  $,  are  not 
permitted  by  the  ANSI  standard. 

M  -  Programs  must  be  divided  into 

sections,  each  of  which  performs  a 
given  task.  Before  each  section, 
comment  cards  must  briefly  describe 
the  task  being  done  by  the  section. 

M  -  Include  enough  explanatory  comments 
so  that  the  reader  can  easily  fol¬ 
low  the  code.  Consider  comments  to 
be  the  equivalent  of  the  text  of  a 
book.  A  well-documented  FORTRAN 
program  will  often  have  more  com¬ 
ment  statements  (C-statements)  than 
executable  statements.  Contrary 
to  some  people's  belief,  comment 
statements  do  not  slow  down  the 
execution  of  a  program.  Their 
absence,  however,  significantly 
impedes  human  comprehension. 
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M  -  Groups  of  comment  statements  must 
be  set  off  by  at  least  one  blank 


comment  card  before  and  after  the 
group . 

M  -  Write  comment  statements  so  that 

they  will  help  the  reader  to  under¬ 
stand  the  program.  A  program 
comment  of  the  form  "add  1  to  N" 
before  the  statement  N=N+1  is  no 
help.  The  goal  is  to  anticipate 
the  questions  the  reader  will  have 
and  to  answer  them  in  advance. 

M  -  Display  comments  so  that  they  will 
stand  out  clearly. 

M  -  Do  not  refer  to  specific  statement 
labels  (numbers)  in  comment  state¬ 
ments  or  in  FORMAT  statements  (for 
debugging  printout  for  example). 
Because  the  program  may  be  rese¬ 
quenced  later,  such  comments  and 
printed  messages  could,  as  a 
consequence,  become  incorrect  and 
grossly  misleading. 

M  -  Each  major  decision  point  in  a 
subroutine  or  main  program  must 
have  comment  cards  explaining  the 
decision. 

M  -  Do  not  extend  the  text  of  comments 
into  columns  73  through  80,  because 
these  columns  may  be  used  to 
sequence  the  card  deck  at  a  later 
time . 

S  -  Arrange  code  and  comments  into 
visual  groups  reflective  of  the 
program  logic . 

S  -  Break  up  long  routines  into  sub¬ 
divisions.  Each  subdivision  might 
correspond  to  a  chapter  in  a  math¬ 
ematical  textbook,  with  numerical 
labels  and  subheadings.  Display 
these  subdivisions  by  using  special 
columns  and  "ruling  lines  across 
the  page,"  that  is,  comment  state¬ 
ments  containing  complete  rows  of 
dashes,  asterisks,  etc.  Actually, 
if  routines  are  well  written  they 
should  not  be  so  long  as  to  make 
this  procedure  necessary. 

S  -  Whenever  ?  difficulty  can  be 

foreseen,  insert  a  "warning"  com¬ 
ment  tfoich  is  easily  visible  in  the 


listing,  e.g.,  by  using  asterisks 
or  by  punching  WARNING  in  columns 
that  are  normally  blank. 

S  -  When  using  identation,  keep  the 
spacing  conventions  as  consistent 
as  possible. 

S  -  Programs  should  be  "commented"  as 
they  are  written,  not  afterward. 
This  will  help  expose  errors  in 
logic  and  inadequacies  in  the  code. 
Also  it  should  be  easier  to  anno¬ 
tate  a  piece  of  code  while  it  is 
fresh  in  one's  mind  as  opposed  to 
several  days  (or  weeks)  after  it  is 
wr itten . 

S  -  Meaningful  comments  should  be  added 
to  critical  sections  of  code,  but 
care  should  be  taken  not  to 
detract  the  reader's  eye  from  the 
code  itself. 

L  -  Use  blank  space  liberally,  both 
inter-line  and  intra-line. 

2.8  Blank  Lines 

M  -  Do  not  use  blank  lines.  Instead 

use  a  blank  line  with  a  C  in  column 
one.  Some  compilers  do  not  accept 
completely  blank  lines. 

M  -  Make  heavy  use  of  blank  lines  (with 
a  C  in  column  one)  to  improve 
program  clarity.  They  are  espe¬ 
cially  useful  for  separating 
modules  of  a  program  and  highlight¬ 
ing  critical  sections. 

3.  Language  Elements 

3.1  Constants 

M  -  Use  only  integer,  real,  double 
precision,  complex,  logical,  and 
Hollerith  constants.  Only  these 
constants  are  permitted  by  ANSI 
standard  X3. 9-1966. 

S  -  Whenever  possible,  constant  data 
items  should  be  isolated  in  DATA 
statements.  This  separation  leads 
to  greater  readability  and  easier 
program  modification. 
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3.1.1  Integer  Constants 

No  recommended  guidelines. 

3.1.2  Real  Constants 

M  -  Do  not  divide  by  0.0,  as  it  is 

not  permitted  by  the  ANSI  standards. 
Division  by  zero  may  result  in 
values  such  as  0.,  10“^,  etc., 
depending  on  the  system. 

3.1.3  Double  Precision  Constants 
No  recommended  guidelines. 

3.1.4  Complex  Constants 

No  recommended  guidelines. 

3.1.5  Octal  Constants 

M  -  Do  not  use  octal  or  hexadecimal 

constants,  such  as  525B,  in  FORTRAN 
programs.  These,  unfortunately, 
are  not  permitted  by  the  ANSI 
standard.  This  constraint  is  indeed 
regrettable  because  an  octal  con¬ 
stant  can  often  be  more  easily 
understood  than  a  real  constant 
when  doing  operations  such  as  mask¬ 
ing  and  shifting.  Their  use,  how¬ 
ever,  could  reduce  the  transfer- 
ability  of  the  program. 

3.1.6  Hollerith  Constants 

M  -  Hollerith  constants  used  in  expres¬ 
sions  and  data  statements  must  not 
have  more  than  four,  nor  less  than 
one,  characters,  e.g.,  4HABCD  is 
permissible  but  6HABCDEF  is  not. 
This  restriction  is  due  to  the 
limited  word  length  of  some 
machines. 

M  -  Do  not  use  right- justified  with 
binary  zero  fill  (NRf)  or  left- 
justified  with  binary  zero  fill 
(NLf)  Hollerith  constants,  e.g.,  do 
not  use 

A  -  4LABCD  or  A  -  4RABCD. 

Although  these  constructs  are  very 
valuable,  they  are  not  allowed  by 
ANSI  standard  X3. 9-1966. 


M  -  Do  not  use  Hollerith  constants  in 
statements  other  than  in  the 
argument  of  a  CALL  statement  or  in 
a  data  statement.  Their  use  in 
other  statements  is  not  permitted 
by  the  ANSI  standard  X3. 9-1966. 

S  -  Avoid  use  of  the  apostrophe  or 
other  characters,  such  as  *  or  $ 
to  establish  limits  of  size  of 
Hollerith  constants,  e.g.,  A  = 
'ABCD' .  Although  this  construct  is 
extremely  valuable  and  time-saving, 
it,  regrettably,  is  not  permitted 
by  ANSI  Standard  X3. 9-1966. 
Apostrophes  are  permitted  by  ANSI 
X3. 9-1978  (see  section  9.4). 

3.1.7  Logical  Constants 

M  -  Do  not  use  .T.  or  .F.  to  designate 
logical  constants,  use  only  .TRUE, 
or  .FALSE.  The  abbreviated  forms 
are  not  permitted  by  ANSI  Standard 
X3. 9-1966. 

M  -  Put  a  blank  character  on  either 
side  of  a  logical  constant  to 
improve  readability.  For  example, 

LOGICAL  XI,  X2 

•  •  • 

XI  =  .TRUE. 

X2  =  .FALSE. 

3.2  Variables 

M  -  Variable  names  must  have  no  more 
than  six  alphanumeric  characters 
and  no  special  characters.  This 
restriction  is  unfortunate,  but 
necessary,  due  to  the  inadequa¬ 
cies  of  some  FORTRAN  compilers  and 
the  definition  of  ANSI  standard 
FORTRAN  X3. 9-1966. 

M  -  The  characters  of  a  name  must  not 
be  separated  by  blanks. 

M  -  The  first  character  of  a  variable 
name  must  be  alphabetic. 

M  -  The  standard  naming  conventions, 

namely,  using  the  letters  A  through 
H  and  0  through  Z  as  the  first 
characters  of  real  variables,  and  I 
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through  N  as  the  first  characters 
of  integer  variables,  must  be  used 
and  not  overridden. 

M  -  Variables  that  are  never  used  in  a 
program  or  a  routine  must  be 
eliminated.  Their  presence  reduces 
program  readability  and  wastes 
storage  space. 

M  -  Variable  names  must  not  correspond 
to  FORTRAN  keywords.  A  table  of 
FORTRAN  keywords  is  provided  in 
Appendix  A. 

M  -  Variable  names  must  be  as  descrip¬ 
tive  as  possible  to  improve  read¬ 
ability,  e.g.,  the  variable  name 
for  the  number  of  ships  should  be 
NS11IPS,  not  simply  N,  or  NS. 

M  -  All  variables  must  be  clearly 

defined  before  being  used  in  state¬ 
ments.  Programmers  must  not  assume 
that  variables  are  initialized  to 
zero  (or  any  other  value)  at  the 
beginning  of  a  job. 

M  -  Do  not  put  part  of  a  variable  name 
on  one  line  and  the  rest  of  it  on  a 
continuation  line  below.  Keep 
variable  names  on  the  same  line. 

S  -  Variables  ending  with  the  letter  0 
should  be  avoided .  This  letter  has 
a  tendency  to  be  confused  with  the 
number  zero. 


S  -  One  should  not  use  the  same  vari¬ 
able  name  in  different  contexts  to 
save  memory  space.  Doing  so  is 
confusing  to  the  reader  arid  leads 
to  massive  confusion  if  someone 
later  changes  any  of  the  meanings. 
Modern  computers  typically  are 
never  so  storage-space-liraited  that 
this  practice  is  justified,  except 
possibly  for  very  large  arrays. 


-  Use  symbolic  variables,  rather  than 
integer  constants,  for  array  dimen¬ 
sions  in  the  text,  e.g.,  in  D0- 
loops ,  IF  statements,  I/O  lists, 
etc.  Put  them  all  together  in 
COMMON,  and  initialize  them  all  in 
one  routine.  Then  only  this  routine 


and  the  COMMON/DIMENSION  statements 
need  be  altered  if  the  dimensions 
need  to  be  changed,  e.g.,  to  put 
the  program  on  a  smaller  machine. 

S  -  Avoid  changing  variable  names 

across  subroutine  boundaries.  For 
example,  when  passing  a  parameter 
from  one  routine  to  another,  do  not 
change  its  name  unless  it  is 
unavoidable.  Changing  names  across 
boundaries  makes  the  program  less 
readable . 

3.2. 1  Integer  Variables 

M  -  All  integer  variables  must  begin 
with  the  letter  I,  J,  K,  L,  M, 
or  N. 

S  -  In  general,  counters  (variables 
which  are  incremented  and  tested) 
should  be  integer.  The  increment¬ 
ing  and  testing  of  integers  is 
faster  than  the  incrementing  and 
testing  of  floating  point  (real) 
numbers . 

3.2.2  Real  Variables 

M  -  All  real  variables  must  begin  with 
one  of  the  letters  A  through  H,  or 
0  through  Z. 

3.2.3  Double  Precision  Variables 

M  -  Do  not  use  the  implicit  declaration 
of  double-precision  variables. 

3.2.4  Complex  Variables 

M  -  Do  not  use  integer  complex  vari¬ 
ables.  They  are  not  permitted  by 
the  ANSI  standard. 

3.2.5  Logical  Variables 

No  recommended  guidelines. 

3.3  Arrays 

S  -  The  total  storage  for  any  one  array 
should  not  exceed  32767  (decimal) 
words . 

S  -  The  number  of  subscripts  of  an 
array  in  a  calling  program  should 
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be  Che  same  as  Che  number  of 
subscripts  of  the  corresponding 
array  in  the  called  subroutine. 

For  example,  passing  a  two- 
dimensional  array  to  a  one¬ 
dimensional  array  via  a  subroutine 
call  is  a  confusing  and  error  prone 
practice  and  should  be  avoided. 

That  is,  avoid  constructs  such  as 

PROGRAM  A 

DIMENSION  B(10,10) 

CALL  SUB1  (B) 


END 

SUBROUTINE  SUB1  (C) 
DIMENSION  C(100) 


•  •  •  • 

RETURN 

END 

This  is  not  a  "must"  because  there  are 
instances,  where  this  procedure  is  very 
valuable,  such  as  when  one  wishes  to 
operate  on  columns  of  a  multidimen¬ 
sional  array  with  a  column-oriented 
subroutine.  Also  the  indexing  problem 
is  minimal,  since  virtually  every 
machine  stores  arrays  in  the  same 
column-wise  manner  in  accordance  with 
the  following  table  from  ANSI  Standard 
X3. 9-1966: 


Value  of  a  Subscript 


Dimen 
sionafif  y 

Subic  ript 
Declarator 

Subst  r«pf 

Subscript 

Value 

Maximum 
Subscript  Value 

i 

l  <  1 

<u| 

j 

A 

l  *  Ul 

U  M 

,/  •  4  (/)  1) 

M.B 

i 

1  4  H  (  1 

(a  h  i ) 

u  -  A  U,  1 ) 
•AH  (.  1) 

no  t  £  s 

(U  ij  i  and  (  are  tubit ''ipt  expression* 
I.’ )  4  H  and  t  are  dim'  ision* 


3.3.1  Subscripts 

M  -  The  number  of  subscripts  in  an 
array  appearing  in  an  executable 
statement  must  always  equal  the 
number  of  declared  dimensions  of 
the  array,  except  in  an  EQUIVALENCE 
statement . 


M  -  Do  not  use  expressions  other  than 
the  following  for  subscripts: 

C*V+K 

C*V-K 

C*V 

V+K 

V-K 

V 

K 

where  V  is  an  integer  variable,  and 
C  and  K  are  integer  constants. 

These  are  the  only  subscript 
expressions  permitted  by  ANSI 
standard  X3. 9-1966. 

M  -  Subscript  bounds  must  never  be 

exceeded.  A  subscript  must  never 
be  given  a  value  less  than  one  or 
larger  than  the  maximum  length 
specified  by  the  upper  bound 
declared  for  that  subscript.  This 
rule  is  included  to  increase  agree¬ 
ment  with  X3. 9-1978. 

M  -  Never  use  more  than  three  sub¬ 
scripts.  This  number  is  the 
maximum  permitted  by  the  ANSI 
standard  X3. 9-1966. 

M  -  Do  not  use  implicit  indices  for  the 
first  element  of  an  array.  For 
example,  for  a  singly  dimensioned 
array  A,  declared  by 

DIMENSION  A( 5 ) ,  use 
TEMP  =  A(l) 

not 

TEMP  *  A 

The  lack  of  parentheses  makes  the 
program  significantly  less  readable. 

S  -  If  the  installation's  compiler  has 
an  array  subscript  checking  feature 
use  it,  at  least  during  the  initial 
testing  phases  of  the  program 
development.  Since  the  automatic 
array  subscript  error  checking  fea¬ 
ture  tends  to  slow  down  a  program 
considerably,  it  may  be  desirable 
to  turn  it  off  during  production 
runs . 
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3.3.2  Array  Structure 

S  -  Avoid  making  assumptions  regarding 
the  sequential  order  in  which  array 
elements  are  stored  in  memory.  For 
example,  avoid  using  data  state¬ 
ments  of  the  form 

DIMENSION  A(2,3) 

DATA  A/1.,2.,3.,6.,8.,9./ 

4.  Expressions 

4.1  Arithmetic  Expressions 

4.1.1  Evaluation  of  Expressions 

M  -  Never  assume  that  some  finite 
value,  e.g.,  0.0,  will  be 
substituted  for  a  division  by  0. 

M  -  Always  check,  if  possible,  for  the 
case  when  the  denominator  of  an 
expression  is  zero. 

M  -  Do  not  use  ambiguous  statements 
such  as  N+FUNC(N)*N  where  FUNC(N) 
alters  N.  The  results  of  such  a 
statement  depends  upon  the  compiler 
scanning  algorithm.  If  the 
original  value  of  N  is  not  stored 
in  a  temporary  location,  FUNC(N) 
may  destroy  it. 

M  -  Make  heavy  usage  of  parentheses  to 
improve  program  clarity.  There  is 
no  penalty  in  modern  compilers  for 
use  of  unnecessary  parentheses. 

Do  not  rely  upon  the  left  to  right 
evaluation  of  arithmetic  expres¬ 
sions.  For  example,  write  the 
expression  A/B*C  as  (A/B)*C,  even 
though  it  is  defined  this  way 
according  to  the  ANSI  standard. 

Some  individuals  might  think  it 
means  A/(B*C).  Leave  no  possible 
doubt  as  to  vfoat  the  compiler  will 
do. 

S  -  Break  long  arithmetic  expressions 
into  several  simpler  expressions. 
That  is,  by  using  Intermediate 
variables,  break  an  assignment 
statement  having  a  long  arithmetic 
expression  into  a  series  of  assign¬ 
ments  each  of  which  has  a  simpler 


expression.  This  will  improve  pro¬ 
gram  readability.  For  example, 
instead  of  writing 

A=(B*C)+( ( ( 3  *  *D ) / ( — 3 ) )*X)+(Y*4 ) 

write  P1=B*C 

P2=X*(  ( 3 * *D  )  /  ( —3  )  ) 

P3=Y*4 

A*P1+P2+P3 

L  -  Polynomials  such  as  A*X**4+B*X**3+ 
C*X**2+D*X+E  should  be  programmed 
as  E+X*(D+X*(C+X*(B+X*A)))  when 
efficiency  is  important.  The 
expanded  form  is  preferable  when 
efficiency  is  not  important  because 
it  is  more  readable. 

4.1.2  Type  of  Arithmetic  Expressions 

M  -  Mixed  mode  expressions  must  be 
avoided,  e.g.,  do  not  use  A+B/C+ 
D/7+E/4+F  instead  of  A+B/C+D/7.0+ 
E/4.0+F,  or  RCUT  +  N0RDER*PERD 
instead  of  RCUT  +  FLQATF(NORDER)* 
PERD.  j.ne  ANSI  standard  does  not 
permit  mixed  mode  expressions. 

4.1.3  Exponentiation 

M  -  Integer  expressions  must  be  raised 
to  only  integer  powers,  never  real 
powers . 

M  -  Do  not  use  double  exponentiation 

without  parentheses,  e.g.,  A**B**C. 
This  form  is  not  defined  in  the 
standard,  so  it  may  be  implemented 
as  A**(B**C) ,  or  (A**B)**C.  If  it 
is  necessary  to  use  double  exponen¬ 
tiations,  use  parentheses  to 
explicitly  define  the  meaning 
intended . 

4.2  Relational  Expressions 

The  relational  operators  are:  .GT. 
(greater  than),  .GE.  (greater  than  or 
equal  to),  .LT.  (less  than),  .LE.  (less 
than  or  equal  to),  .EQ.  (equal  to),  and 
.NE.  (not  equal  to).  Relational 
expressions  have  the  form  A1  OP  A2, 
where  A1  and  A2  are  arithmetic  or 
masking  expressions,  and  OP  is  a  rela¬ 
tional  operator. 


continuation  on  a  separate  line 
and  align  conditions  vertically. 


M  -  Relational  operators  must  compare 
only  integer  expressions  with  inte¬ 
ger  expressions  or  real  expressions 
with  either  real  expressions  or 
double  precision  expressions.  Only 
these  comparisons  are  permitted  by 
the  ANSI  Standard  X3. 9-1966. 

M  -  Do  not  use  masking  expressions  with 
relational  operators  to  form  rela¬ 
tional  expressions.  For  example, 
do  not  use  expressions  such  as  (A 
.AND.  B)  .GT.  (M  .AND.  .NOT.  77B) . 
Masking  expressions  are  not  permit¬ 
ted  by  the  ANSI  X3. 9-1966 
standard. 

M  -  Do  not  use  relational  operators  for 
expressions  of  a  COMPLEX  data  type. 
For  example,  do  not  use  expressions 
such  as  AMT  .LT.  (1.,  6.55).  Use 
of  expressions  of  the  COMPLEX  data 
type  in  this  context  is  not  defined 
by  the  ANSI  X3. 9-1966  standard. 

M  -  Put  at  least  one  blank  space  on 

each  side  of  a  relational  operator, 
to  improve  program  readability, 
e  .g  ■ ,  A  •  GT .  B . 

4.3  Logical  Expressions 

Logical  expressions  have  the  form  LI  OP 

L2  OP  L3...0P  LN,  where  LI . LN  are 

logical  operands  or  relational  expres¬ 
sions  and  OP  is  a  logical  operator. 

The  logical  operators  are  .AND.,  .OR., 
and  . NOT . . 

M  -  Do  not  use  .N.  for  .NOT.,  .A.  for 
•AND.,  or  .0.  for  .OR.  These 
abbreviations  are  not  permitted 
by  ANSI  Standard  3.9-1966,  and  they 
make  programs  difficult  to  read. 

M  -  Put  a  blank  character  on  each  side 
of  a  logical  operator  to  improve 
program  readability. 

M  -  When  an  IF  statement  contains 

compound  conditions,  parenthesize 
the  separate  simple  conditions  to 
make  the  range  and  strength  of  the 
logical  operators  (.AND.,  .OR.,  and 
.NOT.)  crystal  clear.  If  there  are 
more  than  two  simple  conditions, 
use  continuation  cards  to  put  each 


S  -  Avoid  unnecessarily  complicated 
logical  expressions,  e.g. 

IF  (A  .AND.  B  .OR.  .NOT.  C)  GO  TO  6 

S  -  Avoid  negative  logical  expressions 
whenever  possible.  Their  positive 
equivalents  are  generally  easier  to 
understand.  For  example,  instead  of 
writing 

IF  (.NOT.  FLAG)  GO  TO  10 
X  =  Y 
GO  "0  20 
10  CONTINUE 
A  =  B 

20  CONTINUE 

write 

IF  (FLAG)  GO  TO  10 
A  =  B 
GO  TO  ?0 
10  CONTINUE 
X  =  Y 

20  CONTINUE 

L  -  Use  only  logical  variables  or 
logical  constants  with  logical 
operations.  This  approach  is 
recommended  only  to  achieve  maxi¬ 
mum  portability  of  programs  through 
compliance  with  X3. 9-1966. 

4.4  Masking  Expressions 

Masking  expressions  are  similar  to 
logical  expressions,  but  the  elements 
of  the  masking  expression  are  of  any 
data  type  (variable,  constant,  or 
expression)  other  than  logical. 

S  -  Avoid  use  of  masking  expressions 

(e.g.,  do  not  use:  KAY  .OR.  63,  or 
•NOT.  55).  This  guideline  is 
suggested  because  such  expressions 
are  not  permitted  by  the  ANSI 
X3. 9-1966  standard,  and  also 
because  they  often  depend  upon  the 
word-length  of  the  computer.  Both 
of  these  factors  reduce  program 
portability.  This  constraint  is 
indeed  unfortunate,  since  masking 
operations  are  extremely  useful  for 
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bit-oriented  operations,  which  are 
awkward  to  perform  in  FORTRAN  in 
any  other  manner . 

5.  Assignment  Statements 

5.1  Arithmetic  Assignment  Statements 

M  -  Do  not  use  assignments  of  the  form 
A=B,  where  (1)  A  is  of  the  integer 
data  type  and  B  is  of  a  complex 
data  type,  (2)  A  is  real  and  B  is 
complex,  (3)  A  is  double  precision 
and  B  is  complex,  or  (4)  A  is  com¬ 
plex  and  B  is  anything  but  complex. 

S  -  Avoid  "run-on"  equations.  When 
possible,  divide  large  equations 
into  meaningful  parts.  This 
approach  will  help  improve  program 
clarity. 

S  -  Do  not  use  assignment  statements 
requiring  implicit  conversion  to 
REAL  or  INTEGER  values.  This 
should  help  avoid  problems  arising 
from  rounding  upon  assignment  to 
variables.  For  example,  avoid 
expressions  such  as  XI  *  I  +  1  or 
I  -  J  +  1.5 


and  depend  upon  the  order  in  which 
it  i s  evaluated. 

6.  Control  Statements 

6.1  GO  TO  Statement 

M  -  Do  not  use  the  GO  TO  statement  to 
achieve  small  gains  in  efficiency 
and  thereby  sacrifice  program 
clarity . 

M  -  Always  put  a  blank  character 
between  the  keywords  GO  and  TO 
when  using  a  GO  TO  statement. 

Also,  put  a  blank  to  the  right  of 
TO  and  GO.  For  example,  use  GO  TO 
5,  not  GOTO  5. 

6.1.1  Unconditional  GO  TO  Statement 

S  -  GO  TO  statements  should  be  avoided 
wherever  possible.  Programs  con¬ 
taining  excessive  GO  TO's  are 
inherently  difficult  to  document 
and  understand,  since  they  tend 
to  have  spaghetti-like  logic.  If 
the  GO  TO  statement  is  used,  it 
should  be  used  in  a  highly- 
controlled  manner. 


fi 


S  -  Put  at  least  one  blank  character  on 
either  side  of  each  equal  (=)  sign, 
to  help  improve  program  readability. 

5.2  Logical  Assignment 

No  recommended  guidelines. 

5.3  Masking  Assignment 

S  -  Avoid  the  use  of  assignments  of  the 
form  V  **  masking  expression.  This 
type  of  assignment  is  not  permitted 
by  the  ANSI  standard,  and  the 
portability  of  programs  is  reduced 
by  its  use. 

5.4  Multiple  Assignment 

M  -  Do  not  use  assignments  of  the  form 
V  ■  «  V£  -  V3...*  expression. 

For  example,  do  not  use  X  ■  Y  - 
Z  »  4.  This  type  of  expression  is 
not  permitted  by  the  ANSI  standard. 
Also,  its  meaning  can  be  ambiguous 


S  -  Where  possible,  use  a  DO  loop,  an 
IF  statement,  or  a  built-in  func¬ 
tion  in  lieu  of  a  GO  TO  statement. 

Example  1  (due  to  Ledgard  and  Chmura, 
see  references) 

Instead  of: 

10  CONTINUE 

IF  (N  .GT.  M)  GO  TO  20 

N  =  N  +  1 
GO  TO  10 
20  CONTINUE 


DO  10  N  -  1,  M 


10  CONTINUE 


Example  2 


Instead  of; 
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IF  (A  .GT.  B)  GO  TO  10 
C  -  B  -  A 
GO  TO  20 
10  CONTINUE 
C  =  A  -  B 
20  CONTINUE 

Use: 

C  -  A  -  B 

IF  (C  .LT.  0.)  C  -  -C 

Or,  better  still,  use: 

C  =  ABS( A  -  B) 

6.1.2  Computed  GO  TO  Statement 

M  -  Do  not  use  an  arithmetic  or  masking 
expression  In  a  computed  GO  TO 
statement.  Use  only  an  Integer 
variable.  For  example,  do  not  use 
GO  TO  (10,  110,  11,  12,  13),  X/Y. 
Use  of  the  latter  is  not  permitted 
by  ANSI  standard  X3. 9-1966. 

M  -  The  right  parenthesis  of  a  computed 
GO  TO  statement  must  always  be 
followed  by  a  comma  to  comply  with 
X3. 9-1966.  For  example,  use 

GO  TO  (10,  20,  30),  L 

not 

GO  TO  (10,  20,  30)  L 

M  -  Do  not  assume  that  an  incorrectly 
computed  GO  TO  variable  will  result 
in  a  default  condition  such  a 
"falling  through."  For  example,  do 
not  use  statements  such  as  GO  TO 
(100,  200,  300),  M  where  M  is  4. 

M  -  If  a  flag  has  more  than  three 

values  and  is  used  for  transfer  of 
control  to  one  of  N  locations,  a 
computed  GO  TO  statement  is  clearer 
than  testing  with  multiple  IF 
statements.  For  example,  use 

GO  TO  (10,  20,  30,  40,  50,  60),  L 

not 

IF  (L-2 )  10,  20,  25 
25  CONTINUE 

IF  (L-4)  30,  40,  45 


45  CONTINUE 

IF  (L-6)  50,  60,  65 
65  CONTINUE 

S  -  Check  each  computed  GO  TO  statement 
for  an  out-of-bounds  value  of  its 
index  variable. 

S  -  Avoid  using  the  computed  GO  TO 
statement,  except  to  simulate 
the  CASE  statement  of  structured 
programming  as  described  in 
Appendix  D. 

6.1.3  ASSIGN  Statement 

M  -  Do  not  use  the  ASSIGN  statement. 

6.1.4  Assigned  GO  TO  Statement 

M  -  Do  not  use  the  assigned  GO  TO 

statement.  It  is  a  form  of  a  pro¬ 
gram  modifying  itself,  and  it  makes 
programs  difficult  to  comprehend 
and  debug.  For  example,  when  one 
sees  an  assigned  GO  TO  statement  in 
a  listing,  one  has  to  make  an  extra 
effort  to  determine  to  where  that 
statement  transfers  control.  These 
disadvantages  outweigh  any  small 
advantages  that  may  be  gained  in 
CPU  time  and  memory  savings.  Also 
It  is  always  possible  to  do  the 
same  thing  another  way,  e.g.  using 
a  computed  GO  TO  statement  or  an  IF 
statement . 

6.2  Arithmetic  IF  Statement 

6.2.1  Three-Branch  Arithmetic  IF  Statement 

M  -  Use  a  three-way  branch  IF  statement 
only  when  the  three  branches  are 
distinct,  e.g.,  IF  (A-80.)  500, 

600,  700  is  acceptable,  but 
IF  (A-80.)  500,  500,  700  is  not. 
Instead  use 

IF  (A  .GT.  80.)  GO  TO  700 
GO  TO  500 

M  -  The  expression  of  an  arithmetic 
IF  statement  must  be  either 
integer,  real,  or  double  precision. 

S  -  The  expression  in  an  IF  statement 
should  explicitly  include  all 
levels  of  parentheses  for  clarity. 
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L  -  When  testing  a  variable  that  can 
assume  N  possible  values,  include 
an  (N+l)st  check  for  the  possibil¬ 
ity  that  the  variable  has  assumed 
an  illegal  value. 

6.2.2  Two-Branch  Arithmetic  IF  Statement 

M  -  Do  not  use  the  two-branch  IF 
statements,  e.g.,  do  not  use 
IF  (X*Y)  10,  20.  It  is  not 
permitted  by  X3. 9-1966. 

6.3  Logical  IF  Statement 

6.3. 1  Standard  Logical  IF  Statement 

This  statement  has  the  form 
IF  (eir)  stat,  where  eir  is  a  logical 
expression  and  stat  is  an  unlabelled 
executable  statement  other  than  DO, 

END,  or  another  standard- fo rm  logical 
IF  statement. 

S  -  Avoid  testing  floating-point 

variables  for  equality,  since  the 
results  can  be  misleading  and 
machine  dependent.  Due  to  the 
inherent  inaccuracies  of  floating¬ 
point  representations,  it  may 
happen  that  a  test  for  a  specific 
number  will  fail  when  the  user 
would  think  it  should  pass.  For 
example,  A  ■  1.-3. 0/3.0  may  result 
in  A  being  set  to  0.0000001  and  a 
subsequent  test  for  (A  .EQ.  0.) 
would  fail.  Instead  of  the  test 

IF  (A  .EQ.  B)  GO  TO  2 

use  a  statement  like 

IF  (  ABS(A-B)  .LE.  l.E-08)  GO  TO  2. 

Tests  for  grea ter- than-or- equal- to 
or  less-than-or-equal-to  are  pre¬ 
ferred  to  tests  for  equality.  This 
guideline  is  not  a  "must"  because 
in  some  circumstances  the  value  of 
the  variable  may  have  been  pre¬ 
viously  set  to  an  "exact"  value. 

S  -  In  IF  statements  of  the  form 

IF  (A  .AND.  B)  (statement)  do  not 
assume  that  both  A  and  B  will  be 
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evaluated  because,  according  to  the 
ANSI  Standard  3.9-1966,  they  don't 
have  to  be.  For  example,  on  the 
Univac  1108  system,  if  A  is  false, 

B  is  not  checked  for  its  status  and 
the  test  fails.  On  the  CDC  6600 
system,  both  A  and  B  are  checked. 

As  an  example,  if  C  is  an  array  of 
size  N  and  if  core  is  preset  to 
negative  infinity,  the  statement 

IF  ((I  .LT.  N)  .AND.  (C(I)  .LE. 

C(I+1)))  GO  TO  100 

would  abort  on  the  CDC  machine  if 
I  =  N  when  C(N+1)  was  evaluated, 
but  it  would  not  abort  on  the  Uni¬ 
vac  system.  This  problem  could  be 
avoided  on  the  CDC  system  by 
replacing  it  with 

IF(I  .GE.  N)  GO  TO  20 
IF(C(I )  .LE.  C(I+1))  GO  TO  100 
20  CONTINUE 

L  -  If  a  few  statements  are  to  be 

executed  only  if  some  condition  is 
met,  it  is  a  simple  matter  to  set 
a  logical  value  TRUE  if  the  con¬ 
dition  is  true,  and  then  use  a 
series  of  logical  IF's  containing 
just  that  logical  variable  as  the 
logical  expression.  The  loss  in 
computer  time  involved  in  repeating 
the  test  of  the  logical  variable  is 
very  small  in  most  cases,  and  will 
be  more  than  compensated  by 
increased  clarity.  This  step  helps 
avoid  use  of  the  GO  TO  statement. 

Example 

OK  *  .TRUE. 

IF(  (I  .GT.  N)  .OR.  (I  .LT.  1))  OK  *= 
.FALSE. 

IF(0K  )  A(I, J)  =  TEMP 

IF ( . NOT .  OK)  WRITE(6 , 9110)  I 

IF( .NOT.  OK)  NERR0R  =  NERROR+1 

6.3.2  Two-Branch  Logical  IF  Statement 

M  -  Do  not  use  the  two-branch  logical 
IF  statement.  For  example,  do  not 
use  statements  such  as 

IF  (  K  .EQ.  100)  60,  70. 

This  statement  is  no:  permitted  by 
the  ANSI  X3. 9-1966  standard. 


6.4  DO  Statement 


6.4.1  DO  Loops 

M  -  DO  loop  variables  must  not  be 
assigned  a  new  value  within  the 
range  of  the  DO-loop.  Specif¬ 
ically,  ,  m2,  and  m3  should 
never  be  changed  while  executing  a 
DO-loop  of  the  form 

DO  n  I  =  m3 ,  m2 ,  m3 

or 

DO  n  I  =  m3 ,  m2 • 

Altering  a  DO  parameter  within  a 
loop  may  produce  varying  results, 
depending  upon  how  the  DO-loop 
feature  was  implemented  in  the  com¬ 
piler  (pre-test,  post-test,  index 
in  core,  index  in  register,  etc.). 
Changing  of  the  DO-loop  variables 
is  not  permitted  by  the  ANSI 
standard.  For  example,  do  not 
write  code  such  as 

DO  15  K  =  1,10 
K  =  K  +  1 
WRITE(5, 2 )K 
15  CONTINUE 
2  FORMAT  (15) 

M  -  Do  not  use  nonpositive  indices  (I, 
m^  ,  m2,  m3)  in  DO-loops. 

Loops  in  the  form  DO  10  I  «  K,J 
where  J  is  less  than  K  may  or  may 
not  be  executed  once,  depending 
upon  where  the  test  for  completion 
is  made.  Non-zero  values  of  these 
indices  are  not  permitted  by  ANSI 
standard  X3. 9-1966.  Although 
statements  such  as  DO  10  I  “  0,1 
are  permitted  in  Univac  FORTRAN, 
they  are  not  legal  in  CDC  FORTRAN. 
Instead,  replace  such  constructs 
with 

DO  10  II  -  1,2 

I  -  II-l 

The  effects  of  negative  incre¬ 
menting  such  as  DO  10  I  *  NP,1,-1 
can  be  achieved  with  the  statements 
such  as 

DO  10  ID  -  1,NP 
I  -  N  P+1 -ID 


M  -  Do  not  use  real  variables  as  DO- 
loop  indices.  Although  some 
machines,  such  as  the  Burroughs 
B5500,  permit  this  feature,  it  is 
not  al Lowed  by  the  ANSI  standard. 

M  -  To  improve  program  clarity,  the 

executable  statements  in  the  range 
of  a  DO  Kop  must  be  indented  at 
least  three  spaces  from  the  DO 
statement  and  terminating  CONTINUE 
statement.  Three  spaces  allow  the 
"DO"  to  stand  out,  and  nested  loops 
will  not  deprive  the  programmer  of 
too  many  card  c o 1 umn s  .  Fo r 
example,  a  DO-loop  must  appear  as 
fol lows : 

DO  10  I  =  1,  NS  HI  PS 
Statement  -  1 
Statement  -  2 


Statement  -  n 
10  CONTINUE 

M  -  Do  not  assume  that  a  DO-loop  is 
always  executed  once. 

M  -  Test  for  the  case  of  zero  itera¬ 
tions  of  a  DO-loop,  if  this  occur¬ 
rence  is  a  possibility.  For 
example : 

I F ( ( K.-J )  .LE.  0)  GO  TO  1 
DO  6  M  =  J,K 


6  CONTINUE 
1  CONTINUE 

M  -  Do  not  assume  that  if  m^  is 

greater  than  m2,  the  loop  will  be 
executed  once.  For  example,  the 
scope  of  DO  10  1=4,  N  where  N=3  may 
not  be  executed  once. 

M  -  Always  put  a  blank  character 
between  the  keyword  DO  and  the 
statement  number  following  it,  and 
between  the  statement  number  and 
the  looping  variable  following  it 
to  improve  clarity.  For  example, 
write  DO  10  I  =  1,  30,  not 
D010I=1,30. 
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M  -  Do  not  use  large  numbers  as  DO 
indices.  Example:  DO  10  1*1,  N 
where  N«2**17.  The  maximum  size 
for  a  looping  index  must  not  exceed 
2**1 5-1 ,  i.e.,  32767.  Although  the 
ANSI  standard  does  not  specify  a 
value,  this  size  is  the  maximum  for 
some  CDC  FORTRAN  compilers. 

M  -  Every  DO  statement  must  refer  to 
its  own  unique  CONTINUE  at  the  end 
of  its  range.  Some  compilers  put 
special  restrictions  on  nested 
DO-loops  that  terminate  on  one 
statement.  The  XDS  Sigma  5/7,  for 
instance,  only  allows  the  innermost 
DO  to  transfer  directly  to  its 
termination  point. 

M  -  Do  not  assume  a  value  of  a  DO  index 
outside  a  DO  loop  if  the  loop  ter¬ 
minated  because  the  control  varia¬ 
ble  is  greater  than  its  associated 
terminal  parameter.  In  this  case 
the  ANSI  Standard  X3. 9-1966  says 
its  value  is  undefined.  If  the 
loop  was  exited  by  a  GO  TO  state¬ 
ment  or  an  arithmetic  IF  statement, 
i.e.,  by  not  satisfying  the  loop, 
the  control  variable  is  defined  and 
is  equal  to  the  most  recent  value. 

M  -  Do  not  transfer  into  a  DO  range. 
Although  such  a  transfer  was  per¬ 
mitted  by  X3. 9-1966,  it  is  not  per¬ 
mitted  by  X3. 9-1978.  The  range  of 
a  DO  loop  may  be  entered  only  by 
the  execution  of  a  DO  statement. 
Also,  most  compilers  do  not  guaran¬ 
tee  the  results  of  such  illegal 
transfers . 

S  -  Invariant  expressions  should  be 

factored  out  of  DO  loops  to  improve 
efficiency  and  program  readability. 
For  example,  instead  of 

DO  25  K  -  1,30 
C  -  3.0 
A(K)  -  C 
25  CONTINUE 

write 

C  -  3.0 

DO  25  K  «  1,30 
A(K)  -  C 
25  CONTINUE 


S  -  Parameterize  DO  loop  indices  rather 
than  using  literals  whenever  pos¬ 
sible.  For  example,  use 
DO  10  I  =  NL,  NH  instead  of 
DO  10  I  =  100,  325. 

6.4.2  Nested  DO  Loops 

M  -  Do  not  use  the  same  single  CONTINUE 
statement  to  terminate  nested  DO 
loops .  Always  end  each  DO  Loop 
with  its  own  unique  CONTINUE 
statement.  This  convention  should 
help  isolate  bodies  of  DO  loops  and 
thereby  lead  to  a  clearer  code. 

For  example,  instead  of 

DO  10  I =H, L 

DO  10  K=KL , KH 

10  CONTINUE 

use 

DO  10  I  =  H,  L 

DO  20  K  *  XL,  KH 


20  CONTINUE 
10  CONTINUE 

M  -  DO  loops  must  not  be  nested  more 
than  25  deep.  Although  the  ANSI 
standard  does  not  have  a  limit, 
certain  IBM  FORTRAN  compilers  have 
25  as  an  upper  limit.  As  a 
practical  matter  and  to  preserve 
readability,  DO  loops  should  not  be 
more  than  four  deep. 

M  -  The  range  of  a  contained  DO  must  be 
a  subset  of  the  range  of  the  con¬ 
taining  DO. 

6.5  CONTINUE  Statement 

M  -  Always  end  each  DO  loop  with  its 
own  unique  CONTINUE  statement. 

S  -  Use  CONTINUE  statements  liberally 
to  improve  program  clarity  and 
to  facilitate  debugging. 

S  -  Put  blank  comment  statements  before 
and  after  each  CONTINUE  statement 
that  is  a  major  decision  point  in 
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program.  Add  additional  comment 
statements  to  explain  the  decision 
being  made. 

6.6  PAUSE  Statement 

M  -  Do  not  use  the  PAUSE  statement. 

Some  computer  facilities  do  not 
permit  its  use,  even  though  it  is 
permitted  by  ANSI  Standard 
X3. 9-1966. 

6.7  STOP  Statement 

M  -  Do  not  use  the  form  of  the  stop 
statement,  STOP  ^C...C^,  where 
C...C  is  a  string  of  characters. 

Use  only  the  simple  four-character 
STOP,  or  STOP  n,  where  n  is  an 
actual  digit  string  of  length  one 
to  five.  The  character  form  is  not 
permitted  by  ANSI  Standard  X3.9- 
1%6. 

6.8  END  Statement 

M  -  Do  not  put  a  statement  label 
(number)  on  an  END  statement. 

Such  a  label  is  not  permitted  by 
the  ANSI  standard. 

M  -  Every  program  must  physically 

terminate  with  an  END  statement. 

6.9  RETURN  Statement 

M  -  Do  not  use  return  statements  of  the 
form  RETURN  i.  This  form  is  not 
permitted  by  the  ANSI  standard. 

Use  only  the  six-character  form, 
RETURN. 

M  -  Do  not  use  a  RETURN  statement  in 
the  main  program.  A  RETURN  state¬ 
ment  may  appear  only  in  a  procedure 
subprogram,  according  to  ANSI 
Standard  3.9-1966. 

M  -  Use  at  most  one  RETURN  statement 
per  subroutine.  Although  the  use 
of  more  than  one  RETURN  is  permit¬ 
ted  by  the  ANSI  standard,  it  can 
lead  to  poorly  structured  programs, 
since  it  defeats  the  one-in  one- 
out  principle  of  structured  pro¬ 
gramming. 


M  -  A  RETURN  statement  must  be  used 

only  as  the  last  executable  state¬ 
ment  of  a  subroutine  or  function. 
This  convention  will  help  produce 
one-in/one-out  control  structures. 
Some  machines  permit  the  END  state¬ 
ment  to  act  also  as  a  normal  RETURN 
statement,  but  other  machines 
require  at  least  one  RETURN  state¬ 
ment  before  the  END.  Always 
include  the  RETURN  statement. 

7.  Specification  Statements 

M  -  Keep  all  spec i f icatio  i  statements 
at  the  beginning  of  routines  (pro¬ 
grams,  subroutines,  or  functions). 

M  -  When  used,  specification  statements 
must  appear  in  the  following  order: 

TYPE 

DIMENS  ION 
COMMON 

EQUIVALENCE  (to  be  avoided,  if 
possible;  see  Section  7.4) 

M  -  Do  not  scatter  specification 

statements.  Group  all  DIMENSION 
statements  together.  Similarly, 
group  COMMON  blocks  and  DATA 
statements  together.  Incremental 
compilers  cannot  handle  scattered 
type,  DIMENSION,  and  DATA  state¬ 
ments;  yet  this  form  of  compiler 
is  desirable  from  a  speed/user 
interface  standpoint. 

7.1  Type  Statements 

7.1.1  EXPLICIT  Type  Statements 

M  -  The  only  data  types  permitted  are 
INTEGER,  REAL,  DOUBLE  PRECISION, 
COMPLEX  and  LOGICAL 

M  -  The  standard  naming  conventions, 

namely,  using  the  letters  A  through 
H  and  0  through  Z  as  the  first 
characters  of  real  variables,  and  I 
through  N  as  the  first  characters 
of  integer  variables,  must  be  used 
and  not  overridden.  For  example, 
do  not  use  INTEGER  SUM,  A,  B,  or 
REAL  ZERO. 


M  -  Always  Include  the  word  PRECISION 
In  DOUBLE  PRECISION  type  state¬ 
ments.  For  example,  Instead  of 
using  DOUBLE  ALIST,  J,  B,  use 
DOUBLE  PRECISION  ALIST,  J,  B. 

This  statement  is  required  by  ANSI 
standard  X3. 9-1966,  and  also 
improves  program  clarity. 

M  -  Do  not  specify  the  type  of  a  name 
more  than  once  in  a  program  unit, 
as  per  X3. 9-1978. 

7.1.2  IMPLICIT  Type  Statements 

M  -  IMPLICIT  type  statements  must  not 
be  used.  For  example,  do  not  use 
IMPLICIT  INTEGER  (A-F, H) .  These 
statements  are  not  permitted  by  the 
ANSI  standard  3.9-1966.  They  also 
reduce  program  readability. 

7.2  DIMENSION  Statement 

M  -  Do  not  use  more  than  three 
dimensions  in  an  array.  For 
example,  do  not  use  DIMENSION 
A(10,20,30,5).  The  use  of  more 
than  three  dimensions  is  not  per¬ 
mitted  by  ANSI  standard  3.9-1966. 

M  -  If  an  array  appears  in  a  COMMON 
area,  it  must  be  dimensioned 
within  the  COMMON  block  and  not  in 
a  DIMENSION  declaration,  e.g.,  use 

CQMMON/INK/A(100),  B 

not 

DIMENSION  A (100) 

COMMON/INK/A, B 

This  guideline  improves  clarity  and 
conciseness. 

M  -  Do  not  use  adjustable  dimensions  in 
the  main  program.  They  may  appear 
only  in  procedure  subprograms, 
according  to  ANSI  X3. 9-1966.  For 
example,  DIMENSION  A(L,K,M)  is  per¬ 
mitted  in  the  main  program  of 
Univac  1108  FORTRAN  programs,  with 
values  set  by  parameter  cards.  It 
is  not  permitted,  however,  in  CDC 
FORTRAN. 


M  -  Adjustable  dimensions  must  only  be 
integer  variables. 

M  -  In  a  subprogram,  a  symbolic  name 
that  appears  in  a  COMMON  statement 
must  not  identify  an  adjustable 
array . 

L  -  Group  dimensioned  variables  in 
alphabetical  order  under  one 
dimension  declaration.  This  group¬ 
ing  can  improve  program  clarity  by 
making  it  easier  to  find  the 
variables . 

7.3  COMMON  Statement 

M  -  Numbered  COMMON  must  not  be  used. 

It  is  not  permitted  by  the  ANSI 
standard  X3. 9-1966. 

M  -  COMMON  block  names  must  not  exceed 
six  characters. 

M  -  A  given  COMMON  block  must  have  the 
same  number  of  variables,  and  each 
variable  must  have  the  same  number 
of  elements,  independent  of  the 
routine  in  which  the  common  block 
appears . 

M  -  Do  not  declare  a  COMMON  block  name 
more  than  once  in  a  COMMON  state¬ 
ment  or  program  unit. 

M  -  Corresponding  variables  in  COMMON 
blocks  must  use  the  same  names  in 
all  routines. 

M  -  Include  a  COMMON  area  in  a  sub¬ 
routine  only  if  it  is  used  in 
that  subroutine.  Following  this 
guideline  will  improve  program 
readability. 

M  -  Do  not  use  more  than  60  COMMON 
blocks . 

M  -  Do  not  use  blank  COMMON  unless 

absolutely  necessary.  If  necessary, 
lay  out  blank  COMMON  in  one  central 
routine  and  treat  variables  there 
as  if  they  were  global.  This  proce¬ 
dure  assists  in  avoiding  duplica¬ 
tion  and  is  a  form  of  documentation 
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S  -  Avoid  excessive  use  of  labelled 

COMMON.  (Insufficient  blank  COMMON 
may  result  in  inability  to  load  in 
OS/360  due  to  the  loader  sharing 
that  space.) 

S  -  In  specifying  COMMON  block  names, 
leave  space  for  six  characters, 
e.g.,  COMMON /L I NK1  /I.J,  A(100). 
This  guideline  will  simplify 
program  modifiations  should  it  be 
necessary  to  change  a  block  name. 

5  -  When  using  COMMON  be  careful  to 
avoid  the  hazards  of  context 
effects • 

L  -  Group  associated  variables  in  a 
single  COMMON  area.  Data  types 
having  the  greatest  word  length 
requirements  should  appear  first. 
Within  each  type  of  variable, 
arrays  should  appear  last.  This 
grouping  helps  make  programs  more 
readable . 

7.4  EQUIVALENCE  Sfafement 

S  -  Avoid  using  the  EQUIVALENCE  state¬ 
ment,  except  when  absolutely  neces¬ 
sary  to  save  storage  space. 

Although  permitted  by  the  ANSI 
standard,  this  statement  tends  to 
make  programs  less  readable. 

M  -  Always  include  subscripts  when 
arrays  are  equivalenced .  For 
example,  do  not  assume 

DIMENSION  ZEBRA(IO) 

EQUIVALENCE  (ZEBRA,  TIGER) 

means  the  same  as 

DIMENSION  ZEBRA(IO) 

EQUIVALENCE  (ZEBRA(l),  TIGER(l)) 

M  -  The  number  of  subscript  expressions 
of  an  array  element  name  must  cor¬ 
respond  in  number  to  the  dimen¬ 
sioning  of  the  array  or  declarator, 
in  accordance  with  ANSI  Standard 
X3. 9-1978. 

M  -  The  EQUIVALENCE  statement  is  used 
to  permit  the  sharing  of  storage  by 


two  or  more  entities.  Do  not  use 
it  to  equate  mathematically  two  or 
more  entities. 

L  -  Although  INTEGER  and  REAL  variables 
should  never  needlessly  be  equiva¬ 
lenced  to  each  other,  there  are 
some  instances  when  this  is  very 
valuable,  such  as  when  creating 
data  structures.  In  general,  how¬ 
ever,  avoid  declarations  such  as 
EQUIVALENCE  (A, I),  since  they 
severely  reduce  program  readability. 

7.5  LEVEL  Statement 

M  -  Do  not  use  LEVEL  statements.  They 
are  not  permitted  by  ANSI  standard 
X3. 9-1966. 

7.6  EXTERNAL  Statement 

M  -  If  an  external  procedure  name  is 
used  as  an  argument  to  another 
external  procedure,  it  must  appear 
in  an  EXTERNAL  statement  in  the 
program  unit  in  which  it  is  so 
used,  in  accordance  with  ANSI 
X3. 9-1966. 

S  -  Avoid  EXTERNAL  statements  whenever 
possible.  Although  permitted  by 
ANSI  3.9-1966,  they  are  confusing 
to  many  programmers . 

7.7  DATA  Statement 

M  -  Do  not  use  parentheses  in  DATA 
statements.  For  example,  do  not 
use  DATA  (A  =  3.),  (B  =  4.115). 
Instead,  use  DATA  A,  B/3.,4.115/. 

This  is  an  unfortunate  rule  since 
the  first  form  is  inherrently 
clearer  than  the  second.  The 
reason  for  it  is  that  the  paren¬ 
thesized  form  is  not  permitted  by 
the  ANSI  standard.  To  comply  with 
the  ANSI  standard,  DATA  statements 
must  have  only  the  form  DATA 
Vlist  L/D1 1st  ^/ , . . . Vi stn/Dl istn/ 
where, 

Vlist  «  a  list  of  array  elements  or 
variable  names,  separated  by  com¬ 
mas.  Array  elements  must  have 
integer  constant  subscripts. 
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Dlist  =  a  list  of  one  or  more  of 
the  following  forms,  separated  by 
commas:  a  constant  or  rf*constant, 
where  rf  is  an  integer  constant. 

The  constant  is  repeated  rf  times. 

M  -  The  number  of  elements  in  the  Vlist 
must  equal  the  number  in  the  corre¬ 
sponding  Dlist. 

M  -  The  type  of  the  constant  in  the 
Dlist  must  agree  with  the  type 
associated  with  the  corresponding 
name  in  the  Vlist. 

M  -  Do  not  use  an  implied  DO  in  a  DATA 
statement.  For  example,  do  not  use 
DATA  ( A( I ) ,  I =1 , 10) /I . , 2 . , 3 . ,  7*2.5/. 

Unfortunately,  the  implied  loop  is 
not  permitted  by  the  ANSI  stand¬ 
ard.  It  is,  however,  far  superior 
to  just  using  the  array  name 
(especially  for  two  or  three 
dimensional  arrays).  For  example, 
the  implied  loop  is  easier  to  read 
and  write,  and  is  less  error  prone 
than  the  following: 

DATA  A  /I . , 2. ,3. ,2. 5, 2. 5, 2. 5, 

2. 5, 2. 5, 2. 5, 2.  5/ 

Unfortunately,  the  ANSI  recommendations 

are: 

DATA  A(l),  A(2 ) ,  A(3),  A(4  ) ,  A(5), 

+  A(6),  A(7) ,  A(8) ,  A(9 ) , 

+  A(10)/l.,2. ,3. ,2. 5, 2. 5, 2. 5 

+  2.5,2. 5,2. 5,2.5/ 

or 

DATA  A(l)/l./,A(2)/2./,A(3)/3./, 

+  A(4)/2.5/,A(5)/2.5/,A(6)/2.5/, 

+  A(7)/2.5/,A(8)/2.5/,A(9)/2.5/, 

+  A(10)/2.5/ 

M  -  An  initially  defined  variable  or 
array  element  may  not  be  in  blank 
common,  according  to  X3. 9-1966. 

M  -  A  variable  or  array  element  in  a 
labeled  COMMON  block  may  be 
initially  defined  in  only  a  block 
data  subprogram,  in  accordance  with 
X3. 9-1966. 


S  -  Avoid  defining  the  value  of  the 
same  variable  in  several  places 
throughout  a  program.  For  example, 
avoid  setting  the  variable  PI  = 
3.14159  in  several  subroutines.  It 
would  be  better  to  initialize  this 
variable  once,  and  pass  it  to  other 
routines  via  a  COMMON  block. 

8.  Programs,  Subprograms,  and  Procedures 

A  program  unit  consists  of  a  set  of 
FORTRAN  statements,  with  comments,  fol¬ 
lowed  by  an  END  card.  A  main  program 
is  a  program  unit  that  does  not  begin 
with  a  SUBROUTINE,  FUNCTION,  or  BLOCK 
DATA  statement.  It  can  be  used  as  a 
self-contained  computing  procedure.  A 
subprogram  is  a  program  unit  that 
begins  with  SUBROUTINE,  FUNCTION,  or  a 
BLOCK  DATA  statement. 

8.1  Main  Programs 

M  -  The  beginning  of  the  text  of  the 

main  program  must  describe,  in  com¬ 
ment  cards,  the  following: 

(1)  -  The  purpose  of  the  program. 

(2)  -  The  author(s)  name,  address, 
organization,  and  phone  number. 

(3)  -  The  version  number  of  the 
program . 

(4)  -  The  date  of  the  first  program 
compilation . 

(5)  -  The  date  the  program  was  last 
updated . 

(6)  -  The  organization  for  which  the 
program  was  written. 

(7)  -  The  processing  performed  by  the 
program . 

(8)  -  A  listing  of  external  reports, 
books,  or  other  documents  describing 
the  algorithms  used,  or  other  infor¬ 
mation  about  the  program. 

(9)  -  A  list  of  COMMON  block  variables 
modified  by  the  main  program. 
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(10)  -  A  description  of  the  card  input 
required  by  the  program  (optional). 

(11)  -  The  names  and  contents  (briefly 
described)  of  all  files  (tape  or  disk) 
written  and/or  read  by  the  program. 

(12)  -  The  names  of  subroutines  in 
which  the  above  files  are  read  or 
written  (optional). 

(13)  -  A  description  of  the  output 
produced  by  the  program  (optional). 

(14)  -  A  list  of  "options"  available  in 
the  program  (optional). 

(15)  -  A  list  of  changes  made  to  the 
program  and  dates  of  those  changes 
(optional) . 

M  -  The  main  program  must  have  no  more 
than  50  executable  statements. 
Longer  programs  are  generally  dif¬ 
ficult  to  understand  and  maintain. 

M  -  If  an  entity  of  a  given  common 

block  is  given  an  initial  value  in 
a  BLOCK  DATA  subprogram,  a  complete 
set  of  specification  statements  for 
the  entire  block  must  be  Included. 
This  is  required  by  X3. 9-1966. 

S  -  Use  a  top-down  approach  when 
designing  programs. 

8.2  Block  Data  Subprogram 

M  -  Do  not  use  BLOCK  DATA  subroutines 
that  have  names.  They  are  not 
permitted  by  ANSI  Standard  X3.9- 
1966.  Use  only  unnamed  BLOCK  DATA 
statements . 

M  -  A  program  must  contain  no  more  than 
one  BLOCK  DATA  subprogram.  (In 
compliance  with  X3. 9-1978). 

8.3  Procedures 

M  -  Make  frequent  use  of  functions  and 
subprograms  to  clarify  and  modular¬ 
ize  the  source  code. 


M  -  Main  programs,  subroutines,  and 

functions  should  be  kept  to  a  mini¬ 
mum  number  of  lines.  They  must 
have  no  more  than  50  executable 
statements.  This  constraint  helps 
to  make  programs  more  understand¬ 
able  by  reducing  the  need  for  the 
programmer  to  keep  in  mind  the 
actions  of  large  blocks  of  code. 

M  -  At  the  beginning  of  each  procedure, 
a  blank  comment  statement  must  be 
followed  by  a  set  of  comment  state¬ 
ments  which  describe  what  the 
procedure  does  and  the  meaning  of 
each  of  the  formal  parameters. 
Parameters  must  be  identified  as  to 
whether  they  are  input,  output,  or 
input-output  variables. 

M  -  At  the  beginning  of  each  procedure, 
there  must  be  a  set  of  comments 
indicating  which  common  block  vari¬ 
ables  are  modified  by  this  sub¬ 
routine.  These  comments  are  needed 
to  facilitate  maintenance  of  the 
program  and  to  avoid  wasting  time 
searching  through,  cross  reference 
lists . 

M  -  Procedures  must  be  arranged  in  the 
source  code  in  alphabetic  order 
following  the  main  program.  This 
arrangement  makes  programs  signif¬ 
icantly  easier  to  debug  and  under¬ 
stand,  since  it  cuts  down  on  time 
searching  for  subroutines  in  large 
printouts . 

M  -  Procedures  which  are  never  called 
must  be  eliminated  from  the  source 
deck.  Extraneous  routines  waste 
others'  time  trying  to  determine 
their  purpose  and  relevance.  They 
also  waste  memory  space. 

M  -  Always  put  at  least  one  blank 

character  after  the  keyword  CALL. 

M  -  Do  not  use  recursive  procedures. 
Most  compilers  do  not  allow  them. 

S  -  Procedures  should  describe,  in 

comment  statements  at  the  beginning 
of  each  routine,  the  meaning  of 
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internal  variables  used  in  the 
routine . 

S  -  Sections  of  code  likely  to  change 
in  the  future  should  be  isolated 
into  procedures  and  clearly  iden¬ 
tified  whenever  possible. 

S  -  Make  procedures  general  purpose 
whenever  possible. 

L  -  The  comment- statement  list  of 

descriptions  of  the  formal  param¬ 
eters  of  a  procedure  should  appear 
in  alphabetic  order,  thereby  making 
it  easier  to  find  the  description 
of  a  given  variable. 

8.3.1  SUBROUTINE  Subprograms  (also  see 
Section  6.9,  RETURN  statement.) 

M  -  Do  not  use  subroutine  calls  that 

include  a  return  list;  for  example, 
CALL  PGM I ( A, B,C ) ,  RETURNS  (5,10). 
Instead  use  the  simple  RETURN 
statement.  The  return  list  is  not 
permitted  by  ANSI  standard  3.9-1966. 

M  -  Do  not  use  the  RETURN  i  form  of 
returning  from  a  subroutine.  Use 
the  simple  RETURN  statement.  The 
RETURN  i  form  is  not  permitted  by 
the  ANSI  standard  X3. 9-1966. 

M  -  The  symbolic  name  of  the  formal 

parameters  of  a  subroutine  subpro¬ 
gram  must  not  appear  in  an  EQUIVA¬ 
LENCE,  COMMON,  or  DATA  statement  in 
the  subprogram. 

M  -  The  symbolic  name  of  a  subroutine 
must  not  appear  in  any  statement  in 
in  the  subprogram  except  in  the 
symbolic  name  of  the  subroutine 
itself.  This  is  required  by  ANSI 
X3. 9-1966. 

M  -  Do  not  use  a  subroutine  when  a 

function  is  needed.  Use  the  right 
tool  for  the  job. 

M  -  Do  not  use  the  ENTRY  statement. 
Although  its  use  is  permitted  by 
the  ANSI  standards,  it  defeats  the 
one-in/one-out  principle  of  struc¬ 
tured  programming,  since  it  allows 
more  than  one  entrance  into  a 


program  unit, 
to  search  code 
i.e.,  it  makes 
readable . 


Also  it  is  annoying 
looking  for  it, 
a  program  less 


M  -  Do  not  use  any  language  feature 
which  permits  subprograms  defined 
within  other  programs  to  have 
access  to  all  parent  program  vari¬ 
ables.  Some  compilers,  such  as  the 
XDS  Sigma  7,  allow  this  to  occur. 
The  use  of  this  feature  is  not 
permitted  by  the  ANSI  standards. 


8.3.2  FUNCTION  Subprograms 

M  -  Do  not  declare  double-precision 
type  functions  with  just  the 
identifier  DOUBLE;  always  use 
DOUBLE  PRECISION.  The  use  of 
DOUBLE  alone  is  not  permitted 
by  the  ANSI  standard. 

M  -  Always  include  a  RETURN  statement 
in  a  function,  do  not  assume  just 
an  END  stac ent  will  suffice. 

M  -  The  formal  parameters  of  a  function 
must  not  be  assigned  new  values 
within  the  body  of  the  function. 
That  is,  there  must  not  be  any 
input-output  or  output  formal 
parameters;  only  input  parameters 
are  permitted.  If  formal  param¬ 
eters  must  be  changed,  a  subroutine 
must  be  used . 

M  -  Do  not  use  a  function  when  you  need 
a  sub rout i ne . 

M  -  Do  not  alter  COMMON  block  variables 
in  a  function. 

8.3.3  Basic  External  Functions 


M  -  Appendix  B  lists  the  functions 
required  by  X3. 9-1966.  Avoid 
using  any  other  external  function, 
other  than  TAN.  It  is  unfortunate 
TAN,  the  tangent  function,  was  not 
included  in  X3. 9-1966. 

S  -  Avoid  using  the  external  functions 
SINH,  DS1NH,  COSH,  COSH,  DCOSH, 
ACOS,  ASIN,  DTANH ,  DTAN,  CDABS . 
Some  systems  may  not  recognize 
these  routines. 
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8.3.4  Intrinsic  Functions 

M  -  Appendix  C  lists  the  intrinsic 

functions  allowed  by  X3. 9-1966.  Do 
not  use  other  intrinsic  functions. 

S  -  Avoid  using  the  following  intrinsic 
functions  since  some  systems  may 
not  support  them: 


S  -  Avoid  calls  to  routines  that 

manipulate  the  transfer  of  data  to 
and  from  extended  (ECS)  or  large 
(LCS)  core  storage. 

S  -  Avoid  calls  to  routines  that  handle 
terminal  I/O. 

8.3.6  Statement  Functions 


logical  product 
logical  sum 
exclusive  or 
complement 
shifting 
masking 
random  number 
location  of  variable 


AND(X, Y,Z) 
OR(X, Y, Z) 
XOR ( X , Y , Z ) 
COMPL(A) 
SHIFT(A, I) 
MASK(I) 
RANT  (A) 
LOCF(Q) 


Shifting  algorithms  are  usually 
word-size  and  hardware  dependent. 

If  it  is  necessary  to  use  such 
routines,  include  comment  state¬ 
ments  describing  their  purpose. 

8.3.5  Additional  Utility  Subprograms 

S  -  Avoid  all  operating  system  inter¬ 
face  routines,  such  as  calls  to 
DATE,  TIME,  SENSE  SWITCH  settings, 
overlays,  and  recovery  routines. 
These  routines  tend  to  signifi¬ 
cantly  reduce  the  portability  of 
programs  among  different  computers. 
If  they  are  used,  clearly  describe 
their  function  in  comment  cards. 


S  -  Avoid  embedding  system-dependent 
debugging  aids  in  programs. 

S  -  Avoid  using  system-dependent  calls 
to  random  number  generators. 

S  -  Avoid  calls  to  system-dependent 
mass  storage  I/O  routines. 

S  -  Avoid  calls  to  system-dependent 
routines  that  check  for  end-of- 
file,  or  parity  errors. 


M  -  Do  not  use  statement  functions  that 
include  masking  expressions. 

M  -  Aside  from  dummy  arguments,  the 

expression  of  a  statement  function 
may  only  contain  non-Hollerith 
constants,  variable  references, 
intrinsic  function  references, 
references  to  previously  defined 
statement  functions,  and  external 
function  references. 

8.3.7  Procedure  Communication 

M  -  Do  not  use  more  than  60  formal 

parameters  in  each  procedure  call. 
The  ANSI  standard  does  not  specify 
any  limit.  Some  CDC  compilers, 
however,  have  a  limit  of  60 
parameters . 

M  -  With  the  exception  of  a  Hollerith 
constant,  the  actual  arguments  in  a 
subroutine  call  must  agree  in  type 
and  number  with  the  corresponding 
formal  parameters  in  the  sub¬ 
routine,  e.g.,  a  call  to  a  sub¬ 
routine  using  CALL  SUB1(1,1.0)  must 
be  avoided  when  the  subroutine 
begins  as  subroutine  SUB1(A,I). 

The  Hollerith  constant  is  an  excep¬ 
tion  to  the  rule  regarding  agree¬ 
ment  of  type. 

M  -  Literals  roust  never  be  used  as 

arguments  in  subroutine  calls  when 
their  corresponding  formal  param¬ 
eters  can  be  changed  in  the  called 
routine. 


S  -  Avoid  calls  to  other  system- 
dependent  I/O  routines,  such  as 
those  that  give  information  on  size 
of  last  buffer  read  in,  or  that 
define  tape  labels. 


M  -  Do  not  use  multiple  entry  points 
into  a  routine.  Each  subroutine 
and  function  must  have  only  one 
entry  point.  Use  of  more  than  one 
entry  point  defeats  the  one-in/one- 
out  structured-programming  concept. 
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M  -  Do  not  use  variable-length  argument 
strings  in  procedure  calls.  Some 
compilers  will  not  deal  success¬ 
fully  with  missing  arguments  (vari¬ 
able  length)  in  a  subroutine  CALL. 

M  -  The  formal  parameters  of  a  function 
must  not  be  assigned  new  values 
within  the  body  of  the  function. 

M  -  Do  not  assume  subroutines  will  be 
called  with  correct  arguments. 

S  -  The  actual  parameters  of  a  sub¬ 
routine  should  be  listed  so  that 
input  parameters  are  given  first, 
input-output  parameters  are  given 
second,  and  output  parameters  are 
specified  last.  This  listing  order 
should  help  improve  the  readability 
of  the  programs. 

S  -  Calling  sequences  should  be  used  as 
little  as  possible.  COMMON  is  a 
much  more  efficient  method  of  com¬ 
munication  between  program  units. 

S  -  Calls  to  machine-dependent  sub¬ 
routines  should  be  avoided. 

S  -  Parameters  should  always  be  checked 
for  validity  when  read  from  cards, 
files,  or  upon  entering  subrou¬ 
tines.  The  intent  here  is  to 
detect  input  errors  as  early  during 
program  execution  as  possible. 

9.  Input/Output 

9.1  FORTRAN  Record  Length 

M  -  Logical  record  lengths  must  not 
exceed  80  characters. 

S  -  The  record  length  for  print  files 
should  not  exceed  120  characters. 
There  are  some  circumstances,  how¬ 
ever,  such  as  when  making  line 
printer  plots,  where  the  additional 
length  is  necessary. 

9.2  Carriage  Control 

M  -  Use  separate  field  specification 
for  printer  control,  e.g.,  use 
FORMAT  (1H1.7HBUFFER-)  instead  of 
FORMAT  (8H1BUFFER-) . 


9.3  READ  and  WRITE  Statements 

M  -  Do  not  use  PRINT  statements.  These 
are  not  permitted  by  the  ANSI 
standard  X3. 9-1966. 

M  -  Do  not  use  PUNCH  statements.  These 
are  not  permitted  by  ANSI  standard 
X3. 9-1966. 

M  -  A  simple  I/O  list  enclosed  in 
parentheses  is  prohibited  from 
appearing  in  an  I/O  list  (in  com¬ 
pliance  with  X3. 9-1978). 

M  -  Do  not  use  expressions  for  unit 
numbers,  e.g.,  READ(2*K+1 , 10) . 

They  are  not  permitted  by  the  ANSI 
standard  X3. 9-1966.  The  unit 
number  must  be  either  an  integer 
variable  or  an  integer  constant. 

M  -  Assume  the  users  of  a  program  will 
provide  it  with  bad  input  data. 
Always  check  these  data  for 
validity. 

M  -  All  printed  output  must  be  annota¬ 
ted  so  that  it  is  understandable  to 
a  user  who  does  not  understand  the 
inner  workings  of  the  program. 

S  -  All  input  parameters  should  be 
checked  very  closely  for  proper 
values.  Parameters  should  be 
printed  out  with  an  identifying 
label  as  soon  after  input  as 
possible,  to  facilitate  debugging. 

S  -  Avoid  operator  interaction  (type¬ 
writer  I/O).  Some  installations 
may  not  support  this  feature. 

S  -  Avoid  using  alternative  action 
flags;  for  example,  READ  (N,ERR= 
101,END=122) .  These  are  not  per¬ 
mitted  by  the  ANSI  standard.  This 
is  not  a  mandatory  requirement 
because  with  some  FORTRAN  compilers 
(e.g.,  Univac  1108)  they  are  needed 
to  check  for  an  end-of-file,  and  to 
perform  other  file  operations. 

S  -  Check  input  parameters  for  reason¬ 
ableness  and  validity  as  soon  as 
possible  after  they  have  been  read 
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in.  Avoid  beginning  calculations 
without  first  checking  the  inputs. 

S  -  Incorporate  a  debug  switch  in  the 
program  which  will  print  out  useful 
trace  information.  This  switch 
should  be  designed  so  that  it  can 
be  turned  on  and  off  after  the 
program  is  compiled  (i.e.,  at 
execution  time). 

S  -  Make  use  of  as  many  operating  sys¬ 
tem  checks  on  tape  labels  as  pos¬ 
sible.  By  checking  tape  labels  in 
the  software,  one  can  often  avoid 
disasterous  mistakes. 

9.3.1  Formatted 

M  -  For  formatted  I/O,  use  only  write 
statements  of  the  form  WRITE 
(un,fn)  iolist  and  READ  statements 
of  the  form  READ(un,fn)  iolist. 

Here  un  and  fn  identify  the  input/ 
output  unit  and  format  specifica¬ 
tion,  respectively. 

M  -  I/O  device  numbers  must  not  be 
negative.  Negative  numbers  were 
permitted  by  X3. 9-1966,  but  not 
X3. 9-1978. 

S  -  I/O  device  numbers  (un)  often 
depend  upon  the  system.  They 
should,  therefore,  be  referred  to 
symbolically,  e.g.,  NREAD,  NWRITE, 
rather  than  by  literals,  such  as  5 
and  6.  This  practice  facilitates 
moving  the  programs  to  another 
machine  and  also  enables  the  user 
to  easily  modify  his  program  to 
output  to  a  private  file,  Instead 
of  the  system  output  file,  if  he  so 
wishes.  Only  unsubscripted  integer 
variables  should  be  used  for  I/O 
device  numbers. 

9.3.2  Unformatted 

M  -  For  unformatted  I/O,  use  only  the 
form  READ(u)  iolist  or  WRITE(u) 
iolist  to  comply  with  ANSI  standard 
X3. 9-1966. 

S  -  Design  magnetic  tape  outputs  for 
general  comparability  with  other 


machines.  Avoid  complicated  block¬ 
ing  or  binary  (non-formatted)  file 
out  puts . 

9.4  FORAAAT  Statements 

M  -  REAL  constants  must  never  be  read 
from  cards  with  INTEGER  formats  and 
vice  versa. 

M  -  Do  not  use  octal  or  hexadecimal 
specifications  in  FORMAT  state¬ 
ments,  since  they  are  not  permitted 
by  ANSI  standard  X3. 9-1966. 

M  -  In  each  program  module,  all  FORMAT 
statements  must  be  listed  after  all 
executable  statements.  This  makes 
programs  easier  to  debug  and  read. 

M  -  Do  not  use  list-directed  (free- 
field  input)  1/0  statements.  For 
example,  do  not  use  statements  such 
as  READ ( U , * )  iolist  or  READ 
*, iolist.  These  are  not  permitted 
by  ANSI  standard  X3. 9-1966. 

M  -  Do  not  perform  alphanumeric  conver¬ 
sion  of  the  form  rRw. 

M  -  Put  a  comma  after  each  field 

(except  groups  of  more  than  one 
slash  (/))  in  a  FORMAT  statement, 
even  though  the  compiler  may  accept 
the  statement  without  the  commas. 

These  commas  make  FORMAT  statements 
more  readable,  and  some  compilers 
require  their  presence.  For 
example,  do  not  write 

9310  FORMAT  (F10. 0, 9XL1 ) . 

Instead,  write 

9510  FORMAT  (F10.0,  9X,  LI) 

M  -  Put  at  least  one  blank  space  after 
the  comma  following  each  field  in  a 
FORMAT  statement.  This  will  make 
it  easier  to  read  and  modify 
formats  in  the  future. 

M  -  When  formatted  records  are  prepared 
for  printing,  the  first  character 
of  the  record  is  not  printed.  The 
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first  character  determines  vertical 
spacing  as  follows:  blank-one  line, 
O-two  lines,  1  to  the  first  line  of 
the  next  page,  +- no  advance.  These 
are  the  only  control  characters 
allowed  by  ANSI  X3. 9-1966,  and  only 
these  can  be  used. 

M  -  Do  not  use  format-controlled 
records  of  more  than  120  char¬ 
acters  • 

S  -  When  performing  alphanumeric  con¬ 
versions  in  the  form  rAw,  r  should 
be  no  greater  than  4.  This  is 
because  we  can  only  assume  that 
machines  will  have  at  a  minimum  the 
ability  to  pack  four  characters  per 
computer  word. 

S  -  Format  statement  fields  after 

slashes(/)  should  begin  on  a  new 
line.  That  is,  the  record 
terminator  ”/"  that  appears  in  a 
format  statement  should  mark  the 
end  of  the  FORTRAN  text  as  it 
appears  on  a  line  of  the  source 
listing  (except  for  a  succeeding 
comma).  Thus  the  end  of  a  line  on 
the  printer  output  will  correspond 
to  the  end  of  a  line  on  the  FORTRAN 
source  listing,  e  .g  . ,  use 

FORMAT  (16H  NO.  OF  FREQS  -  ,  13  ,/, 
1  17H  NO.  OF  DEPTHS  -  ,  13  ) 


F0RMAT(16H  NO.  OF  FREQS  -  , I3./.17H 
1  NO.  OF  DEPTHS  -  ,13). 

S  -  In  FORMAT  statements  use  the  spec¬ 
ification  form  NH - instead  of 

' - '  .  For  example,  use 

4HABCD,  not  ' ABCD'  (or  *ABCD*) . 
Although  the  apostrophe  notation  is 
a  tremendous  timesaver  for  the  pro¬ 
grammer  since  it  alleviates  the 
need  to  count  characters  (which  is 
highly  error  prone),  it  is  not 
permitted  by  ANSI  standard  X3.9- 
1966.  It  is  permitted  by  X3.9- 
1978  and  is  generally  supported  in 
one  form  or  another  on  most  com¬ 
pilers.  For  maximum  portability, 
it  should  be  avoided. 


S  -  Repeated  spec I  'ieatlons  in  FORMAT 
statements  should  not  be  more  than 
two  deep.  For  example,  avoid 
statements  like  9110  FORMAT  (IX, 
3(15,  2(1X, 13,3(14,  2X) ) ) ) . 

S  -  Separate  multifile  card  format 

statements  by  blank  comment  state¬ 
ments. 

L  -  Following  the  E  or  D  In  an  E  or  D 
output  field,  ,i  -for  —  should  be 
used  prior  t  the  exponent.  This 
increases  compliance  with  ANSI 
X3.9-197H.  ANSI  .<3.9-1966  per¬ 
mitted  a  blank  us  a  replacement  for 
a  +. 

L  -  All  format  statement  numbers  should 
begin  with  9  n.d  have  four  digits. 

L  -  Group  all  input  format  statements 
together  and  precede  with  a  comment 
statement  with  the  word  "INPUT”. 

Put  a  com'-"''  ard,  with  all 
asterisks  t>. .  :  and  after  this 

card,  to  -.a'..  •’  stand  out. 


Group  all  ir 
together  and 
’•OUTPUT'.  A 
cards  as  dr ■; 


‘  >rmat  statements 
< \i ■  with  the  word 
! -risk  comment 
i:  above. 


Group  all  :  .  .  -  ■•d  ;  or  both 

input  and  ;  it  '  'get her  and 
precede  with  i  .  imment  statement 
with  the  word  'INPUT  'OUT  PUT**  .  Add 
asterisk  comment  ards  as  described 
above . 


L  -  Group  all  error  message  format 
statements  together  and  precede 
with  the  words  "ERROR  MESSAGES". 

Add  as  terlsk  comment  cards  as 
described  above. 

9.5  File  Manipulation  Statements 

M  -  A  record  must  not  be  written  after 
an  end  of  file  record  in  a  sequen¬ 
tial  file.  X3. 9-1966  does  not  pro¬ 
hibit  this,  but  X3. 9-1978  does. 

M  -  A  sequential  file  must  not  contain 
both  formatted  and  unformatted 
records . 
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Mixing  of  the  two  is  permitted  by 
X3. 9-1966,  but  not  X3. 9-1978. 

S  -  The  use  of  overlays  should  be 

avoided  (whenever  possible).  They 
are  not  permitted  by  X3. 9-1966. 

S  -  The  use  of  segmentation  should  be 
avoided  (whenever  possible).  It  is 
not  permitted  by  X3. 9-1966. 

S  -  Avoid  special  disc  or  drum-oriented 
instructions.  They  are  not  stand¬ 
ard  forms.  If  necessary,  be  sure 
they  are  veil-isolated  and  clearly 
identified  with  comments. 

S  -  Avoid  making  assumptions  regarding 
number  and  kind  of  peripherals 
ava liable . 

S  -  Isolate  and  clearly  mark  code  that 
checks  for  end-of-files .  This 
practice  should  help  reduce  coding 
changes  necessary  to  transfer  the 
program  to  another  computer.  Such 
statements  should  be  avoided  when¬ 
ever  possible,  because  of  their 
machine  dependence. 

9.6  BUFFER  Statements 

M  -  Do  not  use  BUFFER  statements. 

They  are  not  permitted  by  the  ANSI 
standard  X3. 9-1966. 

9.7  NAMELIST 

M  -  Do  not  use  the  NAMELIST  capability. 
This  is  not  permitted  by  ANSI 
standard  X3. 9-1966. 

9.8  ENCODE  and  DECODE 

M  -  Do  not  use  the  ENCODE  and  DECODE 
facilities.  Their  use  is  not 
permitted  by  ANSI  standard  X3.9- 
1966. 

10.  Miscellaneous  Machine/System  Dependencies 

M  -  Do  not  assume  that  memory  will  be 
zeroed  before  the  program  runs. 

M  -  Whenever  a  variable  has  a  chance  of 
being  used  without  initialization, 
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on  another  sysLem,  always  explic¬ 
itly  initialize  memory  to  zero, 
even  Li  l ne  system  presently  being 
used  does  1l  tor  you.  For  example, 

C  **  CLEAR  ARRAYS 
DO  201  -  1 ,  10 

x  (  I  )  =  0  -  'J 

DO  10  J  =-1,81 

A ( 1 , J )  -  0.0 
10  CONTINUE 
20  CONTINUE 

M  -  Machine-dependent  code  that  cannot 
be  el  :  T.i  :m  '  :.jst  be  isolated  and 
clearly  id-  .titled  with  comment 
cards  . 

M  -  Programs  -.,-t  be  modularized  into 
machine 'sv st  ■-  dependent  and 
independent  si.  lions. 

M  -  Do  not  use  any  code,  such  as  sort¬ 
ing,  that  depones  upon  the  inter¬ 
nal  representation  of  characters. 

M  -  Do  not  use  in.  \  n  decimal  and  octal 
literals  (an  example  of  internal 
representat ions) . 

M  -  Do  not  write  code  that  depends  upon 
BCD,  or  EBCDIC  -.ard  code  differences. 

M  -  Do  no;  use  word,  byte,  character, 
or  system  implementation-dependent 
c  od i ng  . 

M  -  Always  assume  the  character  set 
will  be  different  for  different 
machines.  Do  not  make  programs 
dependent  upon  the  internal  charac¬ 
ter  representation  of  a  particular 
machine . 

M  -  Do  not  use  programming  tricks 
dependent  upon  machine  Idiosyn¬ 
crasies  . 

M  -  Write  your  programs  so  the  machine 
operator  can  use  his  time  and 
talents  efficiently.  For  example, 
don't  require  him  to  set  sense 
switches  or  needlessly  mount  and 
dismount  tapes . 

M  -  Make  your  programs  as  operator- 
proof  as  possible.  Don't  have  a 


program  ask  the  operator  for 
information  if  this  same  informa¬ 
tion  can  be  obtained  from  the 
operating  system  another  way.  For 
example,  don’t  require  him  to  type 
in  the  date. 

S  -  Avoid  assembly  language  interfaces. 
Their  use  is  not  permitted  by  the 
ANSI  standard. 

S  -  When  writing  programs,  estimate  the 
range  of  values  variables  can  take 
and  document  the  same.  The  preci¬ 
sion  of  Integer  and  floating-point 
arithmetic  is  machine  and  software 
dependent.  If  future  systems  have 
fewer  bits  assigned  to  the  char¬ 
acteristic  in  floating-point  repre¬ 
sentations,  for  example,  the  cur¬ 
rent  data  may  generate  over/under¬ 
flows  (which  may  go  undetected). 

S  -  Never  assume  the  computer  operator 
has  done  everything  correctly. 

S  -  Avoid  whenever  possible  multi¬ 
tasking  statements,  e.g.,  state¬ 
ments  such  as  ATTACH  and  DELETE  in 
Sy8tem/360,  the  FORK  statement  in 
the  XDS-940,  and  the  ZIP  statement 
in  the  Burroughs  B5500.  The 
structure  of  most  multitasking  pro¬ 
grams  is  very  complex  and  difficult 
to  debug. 


11.  Summary  of  Fortran  Statements  and 
Recommendations 

The  following  is  a  list  of  FORTRAN 
statements  and  recommendations  regard¬ 
ing  their  use.  This  list  contains 
statements  vAiich  must  not  be  used  under 
any  circumstance  ( — ),  which  can  be 
used  only  vAien  necessary  (-),  which  can 
be  used  at  will  (+) ,  and  which  are 
highly  recommended  (++). 

The  notation  used  here  is  as  follows: 

V  *  variable 

Sn  *  statement  number 

iv  -  integer  variable 

m^ ,  m2,  m3  =  integer  constants 

n  -  integer 
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Section 

See  5.1 

See  5.2 
See  5.3 

See  5.4 


See  6.1 
See  6.1 
See  6.1 
See  6.1 
See  6 . 1 
See  6.1 
See  6.2 
See  6.2 
See  6.2 
See  6.3 
See  6.3 
See  6.4 
See  6.4 
See  6.5 
See  6.6 
See  6.6 
See  6.6 
See  6.7 
See  6.7 
See  6.7 
See  6.8 

See  7.1 


See  7.6 
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No.  Rating 


Assignment  Statements 

V  -  arithmetic  expression  + 

V  =  masking  expression  — 

Multiple  Assignment 

V  «  V^»V2 - =Vn=expression 

Control  Statements 

.  1  GO  TO  Sn 

.2  GO  TO  (Sn^  Sn2 - Snm),  iv 

.2  GO  TO  (Sn^,  Sn2 - Snm),  expression 

.4  GO  TO  iv  (Sn!,  Sn2 - Snm)  — 

.4  GO  TO  iv  (Sn-j^ ,Sn2 - Snm) 

.3  ASSIGN  Sn  to  iv  — 


.1  IF  (arithmetic  exp)  Sn^,  Sn2>  Sn2  + 
.  1  IF  (masking  exp)  Sn^,  Sn2 ,  Sn2  — 
.2  IF  (arithmetic  or  masking  exp)  Sn^,  Sn2 

.  1  IF  (logical  expression  or  relational  exp)  stat  + 
.2  IF  (logical  express  or  relational  exp)  Sn^,  Sn2 

DO  Sn  iv=m!,  ra2,  m3  + 
DO  Sn  iv=m! ,  m2  + 
CONTINUE  ++ 


PAUSE 

PAUSE  n 

PAUSE  +c  . . .ct 

STOP 

STOP  n 

STOP 

END  + 

Type  Declare  on 

INTEGER  name!, . . 

TYPE  INTEGER  name! , * > >  .namen  — 

REAL  name! . ,namen 

TYPE  REAL  name! . . 

COMPLEX  name!  ,  . . .  ,namen  + 

TYPE  COMPLEX  . . — 

DOUBLE  PRECISION  name! .  namen  + 

DOUBLE  name!, - namen 

TY fE  DOUBLE  PRECISION  name!  ,  . .  .naraen 
TYPE  DOUBLE  name!  ,  •  • -naraen 

LOGICAL  name! , . . .namen  + 

TYEE  LOGICAL  name! ,  •  •  .namen  — 

IMPLICIT  type  (ac), • . .typen(ac) 

Declaration 


EXTERNAL  name! , *  *  <namen 
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Storage  Allocation 


See  7.1.1 
See  7.1.1 
See  7.2 


See  7 . 3 
See  7.3 
See  7.3 


See  7.4 

See  7.5 
See  7.7 
See  7.7 


See  8.1 


See  8.3 

See  8.3.2 
See  8.3.2 


See  8.3.1 
See  8.3.1 
See  8.3.1 
See  8.3.1 
See  8.3.1 


type  namei,  (di) 

TYPE  type  name  (di) 

DIMENSION  namej  (d^)...namen  (dn) 

di  array  declarator,  one  to  three  integer  constants; 
or  if  name  is  a  dummy  argument  in  a  subprogram, 
one  to  three  integer  variables  or  constants 
COMMON  Vlt .. .Vn 
COMMON  /blk  name/V1 . . . . , Vn 
COMMON  //Mi,  V2,  •• .Vn 
where  blk  name  symbolic  name  or 

1-7  digits 

//  blank  common 

EQUIVALENCE  (glisti,) ,  . .  .(glistn) 


+ 


+ 

+ 


LEVEL  n  ,a  ^  .  .  .an 

Data  Vlist^/dlist^/. .  Vlistn/dlistn/  + 

Data  (Vlist £  +  dlis^),  . .  .(Vlistn  +dlistn) 

Vlisti  List  of  array  elements,  variable  names,  + 

separated  by  commas 
List  of  array  names, 
implied  DO  list 

dlist  One  or  more  of  the  following  forms  separated 
by  commas: 

constant  + 

rf*  constant  + 

( constant  list) 
rf*  (constant  list) 

constant  list:  list  of  constants  separated 
by  commas 

rf:  integer  constant,  the  constant  or 

constant  list  is  repeated  the  number  of 
times  indicated  by  rf 


Main  Programs 


PROGRAM  Name  + 

PROGRAM  name  ( par ^ , . . .par^)  - 

Subprograms 

Function  name  (pi»*«.pn)  -H- 

type  FUNCTION  name  (pi , • • • pn)where  type  is 

COMPLEX,  DOUBLE  PRECISION,  LOGICAL  -K 

where  type  is  DOUBLE,  INTEGER,  REAL 
SUBROUTINE  name  (pi».*.pn)  -H- 

SUBROUTINE  name  ++ 

SUBROUTINE  name  (pi,...pn)  returns  (b^,..bm) 

SUBROUTINE  name,  RETURNS  (bi,...bn) 

ENTRY  name 
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Statement  Functions 


See  8.3.6 

name  (pi,...pn)  -  expression 

+ 

Subprogram  Control  Statements 

See  8.3.7 

CALL  name 

+ 

See  8.3.7 

CALL  name  (p^,...pn) 

+ 

See  8.3.7 

CALL  name  (pi».*.pn)  RETURNS  (b^,...bm) 

— 

See  8.3.7 

CALL  name,  RETURNS  (b^,...bm) 

— 

See  6.9 

RETURN 

+ 

Seu  6.9 

RETURN  i 

— 

See  8.2 

BLOCK  DATA 

— 

See  8.2 

BLOCK  DATA  name 

— 

Input/Output 

See  9.3 

PRINT  anything 

— 

See  9.3 

PUNCH  anything 

— 

See  9.3.1 

WRITE  (u, fn)  Vllst 

+ 

See  9.3.1 

WRITE  (u,fn) 

+ 

WRITE  fn,  Vlist 

— 

WRITE  fn 

— 

See  9.3.2 

WRITE  (u)  iolist 

- 

See  9.3.2 

WRITE  (u) 

- 

WRITE  (w,*)  iolist 

— 

WRITE  *,  iolist 

— 

See  9.3.1 

READ  (u,fn)  iolist 

+ 

See  9.3.1 

READ  (u,fn) 

+ 

READ  fn,  iolist 

— 

See  9.3.2 

READ  (u)  iolist 

- 

See  9.3.2 

READ  (u) 

- 

See  9.3 

READ  (u,*)  iolist 

— 

See  9.3 

READ  *,  iolist 

— 

See  9.6 

BUFFER  IN  (n,  p)  (a,  b) 

— 

See  9.6 

BUFFER  OUT  (u,  p)  (a,  b) 

— 

See  9.7 

NAMELIST  /group  name/a^ ,.. .an/group  namen/ 

— 

, . . .an/ 

READ(u,  group  name) 

— 

WRITE(u,  group  name) 

— 

See  9.8 

Internal  Transfer  of  Data 

ENCODE  (c,  fn ,  v)  iolist 
DECODE  (c,  fn,  v)  iolist 

File  Manipulation 


REWIND  u  + 

BACKSPACE  u  + 

ENDFILE  u  + 

EOF (U) 

Format  Specification 

S„  FORMAT  (fslt  ...fsn)  + 


fsi  one  o;1  more  field  specifications  separated  by 
commas  and/or  grouped  by  parentheses 
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+  + 


Data  Conversion 


See  9.4 
See  9.4 


See  9.5 


srEw.d 

srEw.dEe 

srEw.dDe 

srFw .d 

srGw  .d 

srDw .d 

r  Iw 
riw  .2 
rLw 
rAw 
rRw 
rOw 
rOw  .z 
rZw 

SrVw.d 

s 

r 

w 

d 

e 

z 

nX 

nH 

*. .  .* 
A...* 

»  t 

•  •  • 

/ 

Tn 

V 


Overlays 


Single  precision  floating-point  with 
exponent 

Floating  point  with  specified  exponent 
length 

Floating  point  with  specified  exponent 
length 

Single-precision  floating-point  without 
exponent 

Single-precision  floating-point  with  or 
without  exponent 

Double-precision  floating-point  with 
exponent 

Decimal  integer  conversion 

Integer  with  specified  minimum  digits 

Logical  conversion 

alphanumeric  conversion 

alphanumeric  conversion 

Octal  integer  conversion 

Octal  with  conversion  with  minimum  number 
Hexadecimal  conversion 
Variable  type  conversion 
Optional  scale  factor  of  from:  nP 
Optional  repetition  factor,  non-zero 
unsigned  integer 

Integer  constant  indicating  field  width 
Integer  constant  indicating  digits  to 
right  of  decimal  point 
Integer  indicating  digits  in  exponent 
field 

Integer  specifying  minimum  number  of 
digits 

Intraline  spacing 

Hollerith 

Hollerith 

Hollerith 

Hollerith 

Format  separator;  indicates 
end  of  FORTRAN  record 
Column  tabulation 
Display  code  substitution 
Numeric  substitution 
Comma  (field  separator) 


Call  OVERLAY  (fname,  i,  j,  recall,  k) 
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12.  Example  Program 

12.1  CNOISE  Model  Before  Application  of 
Guidelines 


PAOCAAH  CNOISE. INPUT. OUTPUT. TAPCS-lNPuT.TAPfi. OUTPUT, 
a  TAPfl  .TAPf  4.  TAPf 34  ) 

c 

C  tNli  PA06AAH  ANALYTICALLY  CALCULATE*  SHIPPING  NOISE 

c  AUTHOPi  J.  J.  COANVN  <  NOAM  3*1)  WITH  §.  W.  SCAJFE  <0*fl) 

C 

C 

CONNON  /PABTSH-  ALPHA, C , SINT, SBC 
C 

DrPtNSIOH  FNAAE (li.P*!#.  7*]. PHI  1  <?*).*«  t«Ni.ri(  l«Mi.rLS<P(|M«i 
•  TOT  <  7*  > , T0TDI*  7*  > , TOT J NT ( T*  J 

C 

LOGICAL  EMDAuH.F ICLD.PAlNTF 

C 

DATA  luNITt. IUNIT4, IUHT3*. SIANM' l . 4, 3S, 4MS1AH- 
C 

CPU  DAT£(|DATU 
RCUlND  IUHT3* 

UfttTC  t IuPT3fc.SBBB)  SIAAM 
BfuINO  lUHITt 
BfalHO  IuNITa 
f NOBUN  •  . FALSE. 

IB  CONTINul 

#€•©«  S . SOM  I  Fnanc 

irtCOTlfi  .NC.  B.B)  «0  TO  BSM 

INPPUM  .  . TBUC ■ 

HAITI (S.SAM  >  FNAHC 
HAITI  <  lUMTM.tBBB  )  FNA4* 

ACAD  (  I  UH1  T  4  *  NOSE C  .FNANC 

ir<£Of « IUNIT4)  NC.  B.§>  60  TO  «4M 

UPITC  (1UNT3B.7BBB)  IMTt.MHC 

•CA*  (IUNIT4)  <PM>A( J  >. An| I .  J  »,  J«  1 . NOBCC » 

WBITCIK.6BM  )  FNAPt.NOSfC.  (  J.PnI0<  J  ).PH||<  J»„  J-l.NOSCC  I 
Af*0<f.ttM>  SAC.PAIMTF 
HAITI ‘ 6.SB7B  i  *AC 

B£«D  ‘  ! jNl T |  i  FNANE.N05CCT. AC£BrH,fBCO,BlHC.TICLD 
!r  '  Ctr  '  !ln!tI  »Z  Mi  6C  ’0  I8K 
w«;*E>f  .SIM  •  TNA"l.AOCPT«,r«f 3.AJNC 
ir  nCSICt.nE .nCSEC  -  GO  t0  •••• 

1*  HQT.r IEL0  i  GO  To  20# 

UBI’C  6.SiS#> 

READ  •  lUNlTi  ,  NTL.BNAkTL.SMOPTM.  .  TL«L  ).L*t ,NTL  I 
*•  T'_  |  •  NTL-I 

wBl’E  6.620A-  NTL1  .  SM&PTm.BNAxU  .  AINC  .  >  TL>  l  i.  L*2.NTL  ' 
ro  lm.htl 

A  L  '  •  .  L  -  1  '  #  A I  NC 
.4*  .v-N^NuE 

sea:'  lliMM  >  ntlDlN.tlOwN.  J  ^.TLDli">  2 -TLO'jNil  ).L»1,NTL0UN) 

2a?  »“un*:njc 

-  i .  #  og  i  b  e  « p '  i  a 

•  B.a 

?<?  3MB  -*1  , NCSEC 
Bfor  MwNJTa  TC’«J  ,  JSB 

:r  PBthTf  yBJTE  6.S2SA.  j.PHl#  j  I.PNI»I J  .TOTi J  ).JSB 
IF ' FIELD  I  GO  TO  4BB 

BE«C  *  I  jn  l  T  i  i  NTl. *"*«*:,.  S-DPT*.  Tl«L  MM.NTl  i 
NTH  .  NTl  I 

:f.PSINTF  W»ITE  S,fe2B0  NTLI  .ShOPTh,ana*tl,binC.  I  TL«  L  1.1..2.NTL  l 
O:  3BB  L • 1 , NT L 
8  L  i  *  f l-l  JiA INC 
3M  CN-lNuf 

°C  •»  I  UNI  T  j  i  NTLDU“.TL£)UPi  l  ,  TLOUNI  a  I.  '  UDUFML  >,L«I  .NTLOuni 

*99 

I(.P«:n»Pi  uA»T| (6.6300 
tOMnT  .  j  i  .  t.B 
03  2BBB  I  •  1 , JSA 
SINT  .  B.B 

ACAD  K iUNl T  4 )  BN  IN. ANA*. SNIPS 
IF«BNIn,GI .BNAXTl r  GO  TO  I ?B# 

ALPHA  •  SHIPS ' l BAAKBANAX - AN  I n BAN IN )S2 . B 

<:  ■  *NiH/BiNc*a.# 

T'-t  •  •  *1 '  C  l  J-TLlCl-l  J  >/B|NCa»BNjN-B<ai-i  i  >*TL  <<  1  -  1  ) 
tfiBNA*  G*  .  Bl  K  |  !  i  GO  T0 

Tl  a  •  '  TJ.,  -  T’„<  *1  -  1  ■  >.B  JNCa<BHA**;«!  -  |  (  Mtl  :«I- f  / 

-ALL  PNBSu"  Bna«-BH|N.BNIN.TU .AHAX. TL2 i 
GO  T-  1 SA4 
'■•a  :  o*.tinjE 

'ALL  PABSlN'  At  K  1  )  -  ANIS.  ANIN.TL  I  .  Al*  1  .  ,  7*.,  «  I  »  > 

J  F  i  B  HA ■  Lt  BNAXTl  GO  TO  6BA 

■a  •  n»: 

GC  Td  9BB 

.CNTINJE 

t?  .  Ana*  A  Inc •  l  B 

I  f  ' BN«  » . C  0  A  *  a  •  GO  TO  9BI 

tl  te  ,  ffiNct(9N««i-*ic2 1 («rciKa ■ 

>--L.  c  BBS  jP  •  BNB»  A<f2  .A.42  i.Tli  C2 ',ANA«,TL2) 

•++  :n'.-.je 

•  a  •  »a  : 

-f  * :  gt  *  a  g:  to  i sba 

[»-  1  ABB  L*r  i  ,»a 

.fc.L  PftBsu"  ATnl ,At L  ■ . TL I L  , Bl L*1  '  ,TL ■ L • I  • ) 

c  'NT  I s jf 
'  CN'  INJ| 

IF  SINf  ,_i.  9 . BBBl  -  GO  TO  l ?#• 

SSI  •  i*  BI*LOGI«<  SIN*  , 

GO  V  l  BAP 
!  ’»•  ONMN'jE 

5DI  •  4B.3 

. BBB  C  *  NT  I  No I 

Si  ;•*?#- AAN6E  AIN  OjTpu» 

I  f i PB  I  NTT  «A|?E t B.B3SB »  I .ANIN.AAAX. SHIPS, SOI. SINT 

TOTIN*. j  ,  .  *0T I  NT i j  > •) I Nf 

2ABB  CONTjNfl 

ir.TQTlNT.j  ov  BBBBl  GO  TO  24M 


•BOA 

•AAA 

C 

C 


TQTDIiJ)  •  *  4 A • • 

QC  TO  2CAP 
CONTINUE 

TOTOliJ)  •  l#. AtALOGlA' TOTINTi j , , 

Continue 

SICTOA  OjTPuT 


IFlPAJNTF.  gB I Tf . 4 , 440#  •  J . TO TDB ' J  I . T OT I NT  I j ) 
HAITI  I  l UNT  JB  _  7 |BA  •  PHIB>  J  ‘.PHll  l  J  I.TOTOli  j  , 
OPNJ  •  ONNI*totjnT( J  • 

3 ABB  continue 


HAITI  S.S4SA  I  J.PmJA  J  i.PhI I < J  ., TOTr  j  I.TOTp|, j  ..TOTJNT.  j  , 

a  j*i. nosec 

! r  0"NI  GT  a  BOB  t  I  GO  34BA 
ONNILI  •  40  B 

GO  fl  3SBB 
140#  CONT  I  Ni,E 

CNNIDI  .  :a  BlALuwIB' ,"N| 

3GB#  COn*in.{ 

-tJTE  G.SSBB  ONn ! LB.CNNl 
GO  *C  I A 


SAAA  FOBNAT, ba iB 
SlBB  fOBMAT'F IB  •.  9*ll 


SAAA  f OtAAT  iHi.iBalSHlP  NOISE  AuN  *a,IAlA. a*#/'/ I 

SASA  f OAAAT i t  Hf , a  Th£  5m i a  COUNT  rjLi  IS  10CNTIFIED  »V  '#, BA1A, *‘t' ' • 
itxaTnCAE  Atca,  13.  a  SCCTOASM/' 

••SM8SCCT0A  NuNBEA  PHIA  t0  »«|l  « DEGAEES  >9' 

3<  3 1  a  I  3  .  3  *2F  \  a  .  I  i 

SA7A  FOANAT. i«b. (Snip  SOLACE  LCuCl  lSa.F7.2,a  Dl.ai 
sill  F CANAr i i m# ' '  t  THE  TiAHSNISSJON  LOSS  F1U  IS  IPCHTIFICA  |v  •*, 
lBNIA.a**  / 

II  TmEAE  IS  a  eccEKEA  ATi,  Fit.  2.  ■  FT.,  A  F  ACQuCNC  V  0F#.Fl|.2,a  HZ. 

3,  and  a  # ANCE  INCAENCnT  0F|.F92,a  NAuTICAL  NILESl) 

S 1 5#  FOANA*  IHB,  »*MC  TAANSNISSION  LOSS  OATA  IS  FOB  A  uMF0*N  FIELD.#  » 
S2AA  FOANAT  I  HA . 1 1*  a  The  A!  AAEi.IS.i  taansNISSION  LOSS  UALUCS  FAO«  A  SmI 
IPPINC  SOuBCC  DEPTH  OH.FI  2.|  ft,,  OUT  to#. F».2.#  NAUTICAL  "IlES.# 

317x«TkE  mast  . a l uE  IS  A*  Range  •  APNCt  INCAEACnt  iB.FI.2.a  N.  A.  > 

4,  THtN  PACCUC  ALONG  |A>  LINE  >  I 
S'SaiSFI  I  » 

S2SA  FOANAT  ini. i5£c*0fl  NbN|EAa.|3.8  'I.FS3.I  TOa.ISl.#  DEGAEES'  HAS 
IA  *G**L  CF  » , r  9  2.1  i-lPS  IN|,l3,a  SECTOAAange  IIHS.ai 
S3AA  FOANAT  |h| 

S3SB  FOAnaT-  I  '  k  t  SE  C  t  CB  -  Range  IIN*.I3,|  (I.UJa  TOl.rj  2.t  n  N.  .  HASa 
I.F9  2.I  SHIPS.  NOISE  ISI.FiA  4.«  01  -ITn  Intensit*  .a.CU  4» 

S4AA  FOANAT  inB.IFOB  SECTOR*. 13.1.  SECTOA  HOISE  tSB.F|*.4,8  Dl  H|t«  INT 
II nS I T  *  •#.£!:. 4.  .. 

S4SA  FOBNAT'  IH|  ,S2**SELT0R  I Nf OBNAt I  ONI  - 
»  S3«# . a  • 

22S» I SEC  TOR  NuNIEB  P-i#  TO  PhIi  iDCCAECS)  ShIPS  NOISE  <»B> 
3|NTENSITv«-. 

4<3ial3.3a2F|B.l.FiS.2.Fi| .4,113.4 >  i 
SSAA  F OAAAT < 1  hi . 2 1 i  >. 32X711MI  i '3|»lMt . 7|x|hI' 

I32X3AH#  THE  ONNIDIAECTIONAL  NOISE  IS.FJA  4.2AH  Dl  «!Th  Intensity  • 
2E I  I .4,2m  I  -  32* 1 H# . 7 1  *  1 m# ' 32k 7 3 ( 1 MB  i  > 

C 

7 AAA  FOAPATi AlA.txIS > 

7|#A  FOANAT. JF IB. 2 i 
C 
C 

caaaaaaaaaaaaaaaaiaaaaaaaBaaaaasMaaiaaaaaaaaoaaBtaBBBatBBBBaiaBaaBBatas 

C  EAAOAS 

caaBaBaaiaaBaBaiiaaaaiaatsaaaaoaaaaaaaassastaaaaafBiBBBBaaBsaaaABSSBSMt 

c 

IMS  CONTINUE 

WHITE <  S , B I IB : 

•>••  FOANATt ImO.ITmE  TAANSNISSION  LOSS  FILE.  lUN!T|,  MAI  MTA  TmAT  DOCS 
»  NOT  COUEA  tn|  (APE  NUNBEA  OF  SCCTOAS  DEFINED  FOB  THIS  fMlA  NOISE 
*#UN. S  1 
GO  TO  SAAB 

C 

121#  continue 

W# I TE  <  S . 1300 > 

I3M  FOANAT. IHB.ITME  TAANSNISSION  LOSS  Fill.  IUNITI.  MAS  NO  DNTA  fob  TH 
BIS  AUN. B  1 

GO  To  Mil 
C 

S4M  CONTINUE 

UAITEtt.lSAA . 

•SIA  F0BNAT. lHO. »TmC  GCONITAy  AND  SMlA  COUNT  FILE.  IUNJT4,  HAS  NO  D«TA 
bfoa  this  #un. « i 
GO  TO  BAAI 

C 

ISIS  continue 

IFiENDAUN)  STOP 
W»ITEiS.|TA« , 

IT##  FOANNT. ImA.iTHEAI  IS  NO  T|TlE  CP#D  FOB  THIS  AUN.BI 
MM  CONTINUE 

WBJTI <  S. 910#  > 

FOANAT. //. iBa.l  ---  PAOGANN  CNOISE  BI9ATE0  IN  PAIN  PAOGAAN  -|i 
CAU  Rf OAT 
STOP  7777? 

END 

SUIAOUTINC  PAASUNt  DCLA.Hl  .TU.I 
C 

c 

CONNON  'PAATfN/  ALPHA, C . SINT . |AC 
C 

El  •  I.IMSAC-TLI  » 

I  •  TLI-Tlj 


c 

C  CHfCC  FOB  FLAT  TL  CU#U|  SC  ME  NT 

C 

I F  (  A|| .  | )  Lt.  | .  M I  >  CO  TO  1M 
I  •  t -tl. •  i'CasciA/1 

•  I NT  .  S INT «ALPHAtlB I •#•-!  iBERPt I  SAC -TLI t ' II . 1C >•<•!-•  ItlnAtCat I  I » 

BE  TUAN 

c 

c 

Iff  CONTINUE 


NOT  REPRODUCIBLE 
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’  t 


EuAl.jAM  |HTia**L  »0I  C  I  »  L  CASE  WhCn  T  -  1  i  -  ▼  *  I  •  1  » 


ii  is  «Mn  lfl< 


SINT  .  s:*> 
•l TJ*N 
1*9 


12.2  CNOISE  Model  After  Application  of 
Guidelines 


MO«>M  CHOI  IK  OUTPUT,  TAPES*  INPUT. TAPf*.  OUTPUT. 

I  TAPtl.TAAt4,T*Pf M  ) 

«  AUPAOtf  *  ThU  PtOCtAN  ANALYTICALLY  CALCULATES  tnc  no* iiontallv 

•  OiaiCTlOKAL  *K»ttHT  K«  mo  l  *f  fut  to  •*!##)«* 

It 

II  AIiTNQ*  -  JOHN  J.  COtHYN 

•  NAVAL  OCEAN  NCtfAICM  AMP  DEVELOPMENT  ACTIVITY 

I  COIf  )|l 

I  NUL  ftATION.  NS  ]M!« 

I  ill  l  il|  4t]( 

It 

I  BASED  ON  (Mllfl  UCtflOH  l.t  tv  AUTMO#  AN p 

It 

i  lAttv  u.  $c»iff 

I  OCfAM  DATA  *VSTfN*  ]NC. 

«  INI  lulCuTlut  llul  lulTf  tit 

i  tOCKVl LLf .  Ap  Stitt 

It  <  Ml  )  111  -  3t)l 

it 

t  uCtSION  M 

It  OATf  or  r  It$T  COAAUATION  •  AAA  f  l  ,  1 |T* 

I  OATI  A# OCA AN  LA»T  UPDATED  -  4  MOW  tilt 

»  aaomam  wAirrcN  rot  »o»pa  com  Ml 

t  S*ON*OA-*(A*  AtOJCCt,  NO# DA  COM  t«t 

it 

t  AtOCEBSlNO  Af If OANt  P  tv  PtOCtM  - THt  INPUT*  TO  CNOIK  APf 

It  t**B*Bat*4*8at*s*9**B*tt*l**ss 

I  tCCTOA  Of  ONCTNv,TMH«Nl**IOH  LOtt  CU#Uf*  A©#  EACH  HCtO«. 

It  SHIP  COUNT*  in  AAN«I  ff CTO#  UN*,  AND  SNIP  tOU#CC  tfUCLt. 

It  TNf  OUTPUT*  UNCtATH  Iff  Nf AN  lltCCTlOMAL  AND 

It  OANItJtICTIONAi  NOIM  IIWCI*.  if  ME  AttUNC  A  At AT  (APTm, 

It  THf  AACA.  A.  Of  A  tANOf  ft  C  TO#  IlN  If  OIUCN  »V  TNC  fXPMBUOM 

It  A«t  .tt<ttaa8-tl*t«  >•< TMCTAS-TNCTA! I. 

It  ir  THI*  #AMt(  tCCTO#  UN  HAt  N  UNtrOMLV  UtTtltUTtD  *M | A* , 

It  TNtN  TNf  MNUTV  01  *N|A*  Aft  UNIT  MAM  .  L**tt*<ti.  IN 

It  Thu  AAMti  HCTtt  IlN  CAN  M  0|TA|N(»  |V  |NT(tMf|M  TMt 

la  IHIA  t€N* I  TV  Aft  UNIT  AACft  OUf*  TH*T*.  §0 

ia  i ARtOA ( ■ i •  saNiA^(tsaai-titta>. 

I»  J*  VI  AttUAf  THf  If C INN  IN*  Of  OAMCf  *JN  J  OCCUtt  AT  AOJMT 

It  K.JI  ON  TNC  TIANtN 1**1  ON  LOSS  CUtWf ,  AN*  |N»«  AT  AtINT 

It  N*JI,  AND  IF  Ut  A«*UNC  THf  TIAM*NI**IOM  LOSE  CU#V<  CAN  M 

II  RfAACtEHTfO  A*  A  L I Nf At  ruNCTION  Of  tANCf  OUft  TNC  ||N. 

ia  THf N  THf  I NTff N* I T Y  AT  THf  tfCflVCI  LOCATION  IfTUClN 

II  AZIMUTHAL  AHCIC*  THf  T A  t  AN*  TMfTA«  *Uf  TO  N  «U<H  tANtl - *f  C TO# 

II  UN*  I*  GIViM  *V 

II  I*  futtrot  J*t  TO  N  OfifuN  rot  I  *K I J  iTO  Ai J  I  OT  ft|  J»|l 

It  riHCtt 

ll  r  c  I , J  i  • lNTfctAL  oui*  a  rtOM  till  TO  1 1 1 « t  •  or 

II  L ANIOA 1 B  1 1  1 1 1 1  (  *  -  T  •  I , t  )  j / 1 1  I 

II  WMfAE  S  I*  THf  Jm  1 A  ■,'IUtCf  LfUfl  'IN  l*i 

»«  T '  « . #  I  •  *-f  TtANfNISSION  LOtt  IN  »(CTOt  I  AT 

It  PANyE  A 

it  ’■•;.»  .'’'t  .-h;  :«*  if  tvAiuATic  f«*cUv. 

II  tt  T ,  J  .*  i -A:  J  ,.*.  I  IIA  tOO  I •«  t  J  :  TO  NiJ, 

ia  thih  it  a  i  .  nf  * 

it  »  ■  I.  *  ■•alpha,  j  >U«A.r  in 

r»  £»a  0' i  »a*i i*i  i - o * j  *<#' i«i /- l  o <t  ■ 

It  f *A  D'  I  t*i  I  I  -or | iliti p  |  D'  I  • 

It 

It  .H|Of  t'i  -;»<s  a i |  i  i'll  AMD 
It  D<  I  -C  1  l '  It  AND 

II  C  •  1  ■ ' INi I *A ‘ l »  i 

»l  LN.NATUtAl  LOC  tUNCTJON 

II  I  KA  •!  KAONf NT | AL  f  UNC T I ON 

II  ir  |(  |  ft  THEN 

it  t  ( i,  j  >•  alpha i  j  iitiBK  i  $  -  a 1 1 1 '  1 1  > i  ( t  <  i  •  i  nts-*<  i  iiat  »/* 

It  VNflf  ALPHA! J  I  • LAN* DA ( t  J 't  t  0*  THf  J - TN  tANCf  ICCTot  SIN 

II 

II  IN  »uANAt  v ,  CHQIU  DCTftNINC*  THf  m.ji,  *UN«  Tn*#. 

II  AND  TAKE*  Th«  It  LOC  TO  |A*E  It  TO  OUASN  ThC  MCTQA 

la  AND  ONNltltfcriONAL  NO I *f  LfKCL*  DOC  TO  «U#rtCC  *N| A* , 

It 

II  the  CHOI  It  SVSTfN  I*  C  OMNI IIEP  or  TH#CC.  OATIONALLV  fti», 

II  AtOCtANt  •  llANAt.siANTL.CNOltf  ,  AN*  0#T|ONAUV.  IIANAP  . 

It  At 04# AN*  *l*NAff,*l*#H,AN|  1 2 ANA*  WCtf  0#I«INALLV  NIIMI 

II  TO  MOM  WITH  THf  HONTf  CAOIO  AN*  It  NT  NOIM  AN#  U#NAL  IKttt 


tticriv.  AtOOtAN  •  1  AAAt  Of NftATC*  CHIP  COUNTS  IN  DACCIMII 
•fCTOA-tANOC  UN*  *  I  AN##  UTILIZES  A  PACK  Cl  *Nl##|NO  MNUTV 

rut  AN*  CAtO  INPUT  THAT  ME  INC*  A  UCTOV-tANOf  ||*  Qf  ONfTlT . 
A  SACCIALLV  rotAATTCD  TtANSN I **ION  LO**(TL)  Alt!  If 
OCNCIATIO  *V  f I ANTI ,  TL  CUtUfl  AM  INPUT  TO  *I##TL  rtOA 
CM**,  A  *Af  rotAATTf*  *111.  00  A  'TACV  f*ONATT|*  flLt. 
THEN,  r#ON  SELECTED  TL  INPUT  r ILK*  AO#  CtCM  SfCTOO*  ONE 
A 00  *NtAAIN«  AN*  ONE  AO#  A  TMOtt  SOUttCC  -  *|A#TL  Of NE NATES 
TMO  TL  CUtuCS  HAUINO  A  CONSTANT  tAMOf  J  NCtCAfNT .  CNOIM 
UTILIZE*  The  *MIA  COUNT  AN*  OfOAfTlY  f|L|.  THE  TL  THE. 

AN*  CM*  INPUT*  TO  OCNftATI  AO#  EACH  EfCTOt  THE  N#|OC  DUE 
TO  *NIPP|N0  ThC  SnIPPInO  NOISE  AND  TnE  tECTOO  ANOLEf 
AM  OUTPUT  TO  A  AILC  IN  THE  SANE  FOONAT  At  A  UM  Of NCtATf* 
AILC.  OtAAA*  {ft  A  At 00# AN  THAT  tNTfNO|Tv  AIM  THf  flAA 
100  CNOISO  SHIPAINO  NO  ICE  WITH  A  ANN  I  QINf  NATE  B  MIN*  NOItf. 

•EACMNCCt'  J.  J.CO#nvn.  •«  *tNPLI  ANALYTICAL  Mi  If  NT 

aaiaataaat  noim  #o#CL.‘  nooda  com  Ml.  tent  oa 
PAPE#  tMMNTC#  AT  MTN  NCETINO  OA 
ACOUfTlCAL  IOC  1 1 TV  OA  ANE01CA,  ATLANTA.  OCOOOIA. 


I  k-  ICAlM.'CPK-m  CONAuTf t  AtOCtAM  SvSTCA.* 
NCNO  TO  .  COtNVN,  *  OCTODCt  IfT*. ODSI , INC . 


I  MA4  .  I*  INANE 'I  I.IM.ID 

I  Alt.*  lit*  ftC 

*  Ll  I*  "tlNTr 

ia  NAV  BE  POSITIONED  IN  |A(  C I A  If  0  COLUNNS  Ml  TM 

of c j hal  point  r«ppi**fo> 


If  no*.  ChaaaC Tft  HfADft  AON  TNC 

Ow’Pu’  r  HE 

|xjp  BOUNCE  LEVEL'  IN  Dl > 

P*INT  OUTPUT  MAC 

r  -PIJNT  A  BuNNAtv 

T  PtINT  A  tUNAAtV  AND  DETAILED 

sic  ton  -  nance  bin  data  amp 
TftANSUtUOM  LOS*  Atonic* 

•  'S  Ll*  ’  1LANK  .•*•  I*  ASSUNCD. 


r il(  DE»ctiAT:o«i 

UNl*  NO .  yN 1 t  NAME  • .* 

*  I  CANO  -*> 

*  I  At  In’  0.’* 

1  J  tl  !«*A 


CAtO  INPUT 
pf.NTft  out#ut 

•AANSNJSSION  LOB*  CJ#UCS  OUTPUT 
*y  BIAATL  AtOCtAA 

SfCTOt-tANOt  UN  MONCTtV 
AND  *N  I A  COUNT  AUK 

D*Tf , NJNII B  or  SEC TO#* . 
a2!#l.tmAL  anOCS  DEAIN0  ftfCTO#*, 
••0 1  BE  LIUEL  IN  ffCTO#S<#*> 


ALL  rut*  Atl  •  I N  :«  THt  NAIM  AtOOtAN  l  CHOICE  I 

the  AtiNTjc  ;n.  .uni* 

T|’L|  CAtC.NuNIIP  3'  Mf'OH  AZINuTHAL  ANCLES  DCA IN1MC 
SIC  TO**  .  ;  NA'J  t  Ship  toutcc  tfvll  TtAMBNIBBION  lot* 

Cu*yI*  '0*  n:«  vi:’3t,  r  3*  eac-  tANOE-«Ccrot>DlM 

:•*  *  Mf-ot  •-»  N.Aita  or  *H|P*,H01*I  Due  to  tho*c  ship* 

:n  0l.lN*fH*.  -  •  i*  *n;si  «M|A*I,  TNf  total  no  I  It  <  In  Ml 
rot  THE  SIC’O*  to»a.  «0U|  t  hT*  n*  I  Tv  fO*  SECTO#, 

•»f  *OTa:  oan  :  *  •  *i  •  .-HA  I  HCI*(  .  IN  **  AND  »v  INTENSITY) 


i,;i{  a,  («;i  m  ’  i  : 
*iaens::n  )  naai  tt  • 
•  Dw*  IM 


NNC.i  SEC  M  $1 C  T  ON  j 

-A  »n;,j  0(C  rot  SECTO#  j 

n:**  0*  U  CutUf 

* •  • *  »ahci  • . : 

•  -  .r;-.  * t ANt# 1*1  On  LOSS  VALUES 

'  -  ;’N  SIC»0# 

■  )*  -*N  SI  i  *0#  IN  **  I 

1  '•  tb  sictoa 

♦  '<  •  '94  VNfN  »HfPf  A#f  mo  NONE 
•I  ■  .» 

I  »*.;#  »H*  tl.  A  III.  BET  TO  TOUE 

•  f  :"1  *-A  i .  jNiro#A  r  III* 
c  :  "A,  •  *f  SC  1 1  AT  |  |N  AIOUC 


*  Py  ana  IfNBl’*  »€■  UNIT  tANCf  II  Vi  If  D  *  v  MAM 

*  t  •  C  0»*TANT  .  A.OCIIlfRPl  1  .1 )  I 

•  *#c  *h' p  soutri  .fjii  t«  |*i 

•  MMnI  L  0*  I  C  ■  -  ^»*IT  NjN»E#S  AMD  Mf  AM*  INTO 

•ATA  TCAAI  IT;  I*-'**  '«.(•  H  r*#l«T  *  I  AAh  '  C  .  |  .  4  .  M  ,  *  .  4M*  IAP  . 

■  Ol’ltNINf  DAT|  rtOA  •PfAATJNC  *r*Tf« 

DATA  II  A  «v«*f»  Of  P|  NpE  N*  *9i  T  j  Nf  TNAT  *f  T»<  AATf 

CNMAATtt*  CMA#A(TfP  rotAAT  J  x  Tnf  VAIIAILE  t  |AT| 

CALL  *AT| ■  I *A  * | 


ai  tf  vlND  »Hf  o  »  •«  i  si  *  :  ii 


aa  UNITE  TNf  wO*D  SIAA-  sn  Th(  NOJif  t  |  Ll 
U#ITf  I  I  NO  I  BE,  tut  I  S 1  A#N 

a*  tf w in*  the  *n| aainc  ahc  tbansnibsion  loss  mui 

•Emin*  itl 
•Emin*  i*m|p* 

tt  tnc  *1*0  tiOMirviNC  end  or  c*to  input  it  tCT  to  raitc 

fNDAUN  •  , A*l If . 


It  MAD  IN  TITLf  CAM 
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NOT  REPRODUCIBLE 


niKIMH.NMi  tfNAMt<l).l*l.»0) 

»  CMfCK  Tt  Ml  ir  W  (M-Of-FILI  CMt  nM  M|H  ENCOUNTERED 
If  IT  Ml  BO  TO  BTOTCHCNT  H 

iriCOfUCMBl  -KB.  BO  TO  IB 


If  (  .  HOT  .  (NfAUM  >  00  TO  IBM 
•  STOP  PROGBAH  NORMAll* 


WRITE l IPBJnT , ff BB  ) 
•TOO 


•0  WRITE t  |Pt7NT.fS7S> 

M  MOOT  PROGRAM 

WRITE! IRBINT.IIOO » 

•TOO  TTT? 

CONTINUE 
I NBA UN  •  .Ttut. 

SB  MBIT!  TITLE  ON  PRINTER  AND  ON  NOISE  TUI 

WRITE!  I PR I  NT, SOAR  )  ( f  NAAf  (I  * ,  t • 1 . ZB  > 

WRITE <  f**0}ff  ,####>  tFNAAt  i  J  J. 1*1.10) 

•  a  MOB  Nupili  Of  SECTORS  AND  TITU  from  U  Fill 

BCBBUTU  NOMC.  (FMAAt*  I  ».  I  >I.2B> 

IS  CNCCK  TOO  ON  INC  of  flu 

IfC  tOTlITU  .10.  |.B»  00  TO  30 

as  (MB  Of  FIU  ENCOUNTERED  ON  Tl  flit  -WRITE  MESSAGE  OMB  ABORT 
VOtTC'tOBlMT'MtO) 

yaiTC<lfB|NT,BlBB> 

•TOR  TTTT 
l  CONTINUE 

as  PUT  DATE  AND  NUMBE*  Of  SCCTOBS  ON  noise  rill 

WRITE! INOISI.BTBO  >  IDATC.nOSEC 

St  READ  SECTOR  ANGUS 

RlABiITH  <RMI|( JI.PMttJ).  JM.HOSECl 

«•  POINT  Out  TITU  CARO,  NUMSfR  OF  SECTORS . SCCTOR  NUNOCRS . ANGLE! 

WRITE c  IRBINT.OMS)  I F NAME  <  I  1. 1*1  ,B0 I.NODCC. < J  .ONI  1 1  J  I  .PMItl  J  ». 

I  J-  I .NOffC > 

tl  BCAB  IN  SHIP  SOURCE  LCWCl  AMD  PRINTOUT  FIAC 
RtAOC I  CARD, •• to »  SRC.  PRINTS 
as  PRINT  OUT  SOURCC  iluci  or  *nip 

WB|T|  I  I  PRINT  ,  MOT  )  SRC 

aa 

as 


•t  AS  TITU.  nuNICR  or  SCCTOBS.  Rid  I  VCR  DEPTH. FRf  OUfNCV . 

RANOC  INCREMENT.  AMD  FIELD  FLAG  FROM  ThC  Tl  CURVE  FILE 


Rf AD< ITl  i (f HARE ( I  1. 1 •!.*•». NOSECT. RDCPTH.fREO.RlNC.r ICIB 

C 

c  st  CNCCa  FOR  AM  |N0  Of  rju 
t 

If  (KOfMTU  .KB.  O.B>  00  TO  4# 

e 

C  SS  KND-Of  •FILE  ENCpUMTKRCS  OM  Tl  FU|  -WRITE  BBSS  ABE  AMD  ABORT 

C 

WRIT|<IPRINT.SRSR> 

WBITCl IPRINT.BtBB I 
•TOR  TTTT 

C 

4B  CONTIRUC 
C 

C  «a  PRINT  OUT  TITLE  OM  Tl  FIU.  RECEIVER  BCPTN.  FRCOUCNCV, 

C  IS  AMD  RANGE  INCREMENT 

C 

A  .FrURRJNT.Mi#)  rfNRMfd  >,  tDEPTM.FSf  0.  Blue 

c 

C  SB  CHECK  To  SEC  IF  NUfttCR  Of  SCCTOBS  ON  Tl  MNP  SNIPPING 

C  tl  flits  AGREE 

C 

If (NOSECT  .CO.  NOSEC >  GO  TO  SB 

c 

c  aa  SORT  agree  -write  error  me stoat  and  abort 

C 

WRITE r IPRINT.fBlS) 

WBITCl I PRINT, BIRO ) 

•TOP  TTTT 
C 

•0  CONTINUE 

c 

c  ••  CNCCr  to  see  if  tmc  ti  r if id  is  ACtnurwRiiv  uniform 
c 

IF (  .NOT.  f ICIB  i  00  TO  |#0 
C 

C  St  UNIFORM  FIELD  .SO  WRITE  OUT  MESSAGE 

C 

WBITCl IRBINT.fRlf] 

C 

c  st 

C  SI 


BCOS  NURSES  Of  Tl  POINTS. NRR I BUR  RAMS!  Of  TL  CUBUC  IN  NR. 
SNIP  SOURCE  SCPTNl In  riff >.  TRANSMISSION  loss  VALUES 

BCRBUU)  NTl.BNOKU.  aMBPtU.lUai.l«I.RU) 

NUI-NU-I 

tl  PRINT  BUT  Tl  CURVE 

Wit  Tf  1 1  PRINT  .  BMB  INTI  |  ,  SNBPTM.  RMRMTl .  R  INC  .  I  U  <1 ).  l.«.  NU  ) 

•a  CONPUTC  RANGES  Rf  Tl  POINTS. RBfUNIRG  (RUM.lv  SPACE t 


IBB 


C 

c 

c 

c 

c 

c 


00  IBB  l  • l , NTL 

ru  »*u-i  i  as  Inc 

CONTINUE 

SSREAt  IN  SORE  BUNNV  U  VALUES  FROM  TM|  Tl  f|l( 

REARi  ITl  i  NTlDvN.TiOuR'l  I.TlBUMtK.cTlDUMaMa.NTliUMJ 
CONTINUE 

a  I  CALCULATE  A  CONSTANT  FOR  INTEGRAL 
C'l  .O'AlOCISiEiPi  I  On 

Si  ZERO  OUT  Tm(  OMNIDIRECTIONAL  I  NTKNt  I  TV  UVCL 
OMNI *0.0 

aa  LOOP  Over  SECTORS 
DO  3B0R  J* 1 , NOSE C 

as  READ  NUHtlB  Of  DNIPS  IN  JTN  SECTOR.  AND  NUMBER  Of  ff CTQR  RRMBC 
SS  BINS 

REAS ( I SNIPS /  TOT<  J ) . JSR 

SS  PRINT  OUT  TMf  SECTOR  NURSE R,  SCCTOR  RNBICS.  NO.  Of  SNIPS. 

SS  NO.  Of  aiNf 

Xf(PR|NTf>  WRITE < I PRINT. SS«S  i  i.PNII ( J I.PMlffU I. TOT< J >.JSR 

aa  chcck  to  see  if  there  is  a  unicorn  ti  ncis 
IF(flEiS)  CO  To  4 pa 

as  NOT  UNIFORM.  SO  BEAD  IN  Tl  CUBUt  FpB  THE  SECTOR 

ACAD  I  I T l  l  NTi .RNAKTl, SnOPTm, <TLi l  l,l»| ,NTl  I 
NUI-NU-I 


C 

C  aa  PRINTOUT  Tl  INFO  if  0CRUCSTC0 

c 


c 

c  aa 

c 


300 

c 

t  aa 

c 

c 

400 

c 

c  aa 
c 

c 

c  aa 

c 

c 

C  ff 

c 

c 

c  aa 

c 

c 

c  as 
c  aa 

c 

c 

C  «a 

c  as 

c 

c 

C  SB 

c  at 

c 

c  at 
c  aa 
c  aa 
c  aa 

c 


c 

c  as 
c  aa 

c 

c 

c  aa 

c 

c 

c  aa 
c  as 

c 


c 

SOB 

c 

c  aa 
c  aa 


c 

c  at 
c  ti 

c 


IF(PBINTF)  VR 1 Tf ( IPS  I NT. BOBS  >  NTll .SHBPTH.RNAXTI.R1NC. 

(till  l.L-a.NTU 

CONPUTC  RANGES  FOB  THIS  TL  CURVE 

OO  MR  IM.NTl 
Btll-ll-l ilRINC 
CONTINUE 

•CAD  IN  BURNV  VALUES  Of  H  CURVES 

RCfOUTl)  NTLOON.  TLDuNl  |  >,  UBUNH  >,  I  TLBUNI  L  >,l*|  .NTLBUN  I 

continue 

If  MRINTOUT  RCOuCSTED.GO  T©  a  NfV  PAGE 
IF  iPRINTfi  WRITE ( 1 PR I NT, ft IB i 
ZERO  TOTAL  1NTCNBITV  FOR  JTH  SECTOR 
TOTJNTi J  }’0.0 

i oop  OVER  Range  sirs  for  tme  jrm  sccroR 
DO  (ROB  1M  .JSR 

INITIALIZE  INTERS  I  Tv  FOR  THIS  RANGE  SIN 
SINT  *B.f 

READ  MINI PUN  RANGE  Of  SIN  (RN1N J .MAX I AON  RANGE  OF  SIN  ( RNAX  ) , 
AND  NUNSIR  Of  SHIPS  |N  BIN  IfNIPS) 

R(AD(ISmIPS»  RAIN. RNAX. SHIPS 

CHECK  TO  SEE  If  MININUN  RANGE  Of  DIN  EXCEEDS  MAxINOH 
RANGE  OF  Tl  CUPVC 

IF i  RNIn  ce.  RNAXTII  GO  to  i too 

IT  DOE SN  T.SO  CONPuTI  TNt  SNIP  DENflfv  PER  UNIT  RANGE 
DIVIDED  «t  RANGE. I. f  ALPHA.  FOR  THIS  PIN 

ALPHA  • ( SHIPS'! hAAxaRNAX-RMlHSRNlH ) >lf . R 

GET  APPROPRIATE  INDEX  |N  U  CURVE  CO##f DPONDJNC  TO 
MIHIAUN  RANGE  Of  DIN  AMD  CONPUTC  Tl  AT  RNIN  USING  LINEAR 
INTERPOLATION 

K  I  • ! RNJ  N/RIMC 1*10 

Til*  I  «tl(t  |  l-TUEl-l  »  l/RINC  >t  (RNlH-Rlf  1  -1  )  >»U‘CI*1  » 

CHECK  TO  SEC  IF  RANGE 'SECTOR  SIN  If  SAALLCP  TRAM  RANGE 
INCREMENT  Oh  Tl  CUBvf 

IFlBHAA  QT.  |II|H  GO  TO  KAO 

XT  IS. SO  INTERPOLATE  A  TL  VALUE  AT  ARAB 

TLI.UUUI  )-U(K|-|  n/BINC  JffBRAR-BICI-l  »»  ♦ 

CALL  SUBROUTINE  PRRBUR  TO  EVALUATE  TNf  (NTCBBM  OUtO  TMi 
INTERVAL  MAI  TO  RNIN 

CALL  PARSUNIRRAX-RNIN.BNIN.UI  .RNAX  ,  TIB. OlNT  I 

60  TO  tSBB 
CONTINUE 

EVALUATE  Th(  CONTRIBUTION  TO  ! NTCBBM  FRBR  TMf 
MIN1NUN  RANGE  Of  BIN  TO  TMf  RANOC  BlKI t 

CALL  PRRtUNlBiKI  > -BR|N.RR|N.H| .Rl « 1  I.TUCI  I. SINT) 

CHECK  TO  BEE  If  MAM  I  NUN  RANOC  Of  ||N  It  USB  TMCN  THE  MAX  I  NUN 

BAHGE  Of  Th(  TL  CUBVC 


IFiBNAm  .IT.  RMAXTL  >  GO  TO  BBS 
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NOT  REPRODUCIBLE 


c 

tl  IF  It*  T  SO  *(▼  K I  EGuAl  INK*  or  LAST  VALUE  Of  U  CURVE 

C 

«a  •  mu 

CO  TO  IM 

c 

SOR  CONTI NUC 

C  II  I t  (t  LESS  THAN  lAAiTl.  10  f  IND  THE  INK*  CORRCBRRNB ING 
C  It  to  Tnc  mum  IMOI  IMMXI 

c 

U  •  lOflAD-fflNC  I  •  » 

c 

C  ••  CHECK  TO  SEE  IT  KWI  CORRttAONDS  C*ACUv  TO  Rl*t»  TO  KC 
C  tl  If  INTSMOLATIOM  is  NfCESSARv 

c 

ir>  MAH  .(A.  R  (  K  2  >  1  GO  TO  000 

C 

C  M  CuaLjaTE  CONTRIBUTION  TO  INTEGRAL  TOON  MUM  R<KI>  TO  MA| 

C 

U2  •  IITUIM  l-TK(| )  »/RINC  IK RNA*-R( KB  I  *  ♦  H(KD 
CALL  AAASuRtRNAX-AJKt  ) ,  ■<  K2  1 .  TU  <|  I ,  MAX  .  Ui.  BINT  > 

C 

Nl  CONTINUE 

c 

((•  <2-1 

C 

C  If  enter  TO  SEC  INDICES  RUN  COARECUV. 

C 

ire  n  . CT .  (21  CO  To  ISO# 


:  <1  *0*  EuAt „ATf  C ONTO I Out J on  to  INTICRAL  IRON  range  RlKI  )  to 

C  It  RANGE  »  r 2 

c 

00  IRRR  L  *K  l  ,K2 

CALL  RARSu*'  RINC, till. H<1>. HIM  i.HUM  ), (INTI 
IRRR  CONTINUE 

C 

1  SAC  CONTINUE 

C 

C  tl  CHECK  TO  StE  or  THE  TOTAL  IHTENSITV  CONTRIBUTED  TO  tHf  RANGE  - 1 1 N 

C  It  UP  TO  THIS  AO  In'  . $  J  NT  i  IS  . LE .  1BIK-41  IP  IT  IS  SET  TNE 

C  II  OB  UAL ut  FOR  BIN  To  -4DPI 

C 

IFiSINT  .LE.  R . RRR  t  ’  CO  TO  1?RR 
C 

C  tl  CONUCRT  InTEnSITv  to  dr 

c 

SOD*  »R .B  IALOC  1 1  <  S I  NT  i 
CO  to  IRRR 
c 

1 TRB  CONTINUE 

SBB  •  -4R. 

c 

IBM  CONTINUE 


2400 

MM 

C 

C  tl 

c 


c 

c  II 

C  II 

c 

c 

C  St 

c 

IRRR 

c 

C  II 

c 


c 

C  II 

c  II 

c 


HRR 

c 

C  II 

e 

nf 

c 


C  II 

c 


ARINT  OUT  INFO  FOR  SECTOR  RANK  BIN.  IF  RE RUE ITER  Rv  Mil 

irr  ARINTF  )  u*[r(<  lARfMT.GGlE  »  I .  RAIN.MAK,  SMIAS.SDB,  f  (NT 


ADO  IN  INTENSITY  of  THIS  RANK  SECTOR  BIN  TO  THAT  Of 
The  ENTIRE  JTm  SECTOR 

TOTINTIJJ  *T0T|NT<  J >  4  SINT 

END  OF  LOOA  ON  BANK  BINS  FAR  JTm  SECTOR 

continue 

check  to  SEE  IF  TOTAL  INTENSITY  FOR  SECTOR  IS  GREATER  Than 
-4RDI.  IF  IT  ISh  T  .SET  IT  TO  -40DB . 

I F  i  TOT  I  NT  C  J  j  GT  R.RRRl  )  CO  TO  24RG 
TOTOBtJl  •  -40. i 
CO  TO  MOO 
CONTINUE 

rOTpl I J  1  •  IR.#«AL0GIR( TOTINTeJJ) 

Continue 

hR|TC  Out  SUNNARV  INFO  FOR  THE  ENTfRE  SECTOR.  If  REQUESTED 

IF (ARINTF  I  WRITE i  IARINT . 9«4R  )  J. TOTDD< J > . TOT J NTC J I 

WRITE  SECTOR  ANCLES  AND  TOTAL  SECTOR  DB  UALUC  ON  NOISE  FILE 

WRITE ( I  NO I  SI . O'M  0  i  AMI  1 1 J  ) . AMI ft  J  > , TOTDB  < J  » 

ADD  IN  CONTRIBUTION  OF  TN|f  SECTOR  TO  TOTAL  OMNIDIRECTIONAL 
1NTENSITY(  ONN| | 

OMNI  •  ONNf  .  TOTINTiJl 

EnB  OF  LOOA  ON  IECTORB  lj) 

CONTINUE 

ARJNT  OUT  SUMARV  INFO  FOR  SECTORS 

WRI’C  IARInT , BR40  it  J. AnI| <  J >.Am1*I j >,TOT< J i.TOTBBt J > , T0TINT4 J I . 
J  • 1 .NOSE C  t 

IF  tMC  OANl DIRECT  I ONAL  INTENSITY  IS  LESS  THAN  -4RDB.  SET  it  TO 
-4B  DB 

JF.CRHI  .  gv  •  imp  CO  TO  bibs 

ONNIDB  ■  *40. B 

CC  JSRR 

CONT ;nu( 

con  CRT  Qam j  INTENSITY  to  di 

ONNf  OB  •  iR-Gt  ALOCIRf  OANl  I 
CONTINUE 

Vt  I  Tf  ONN|  DB  VALUE  AND  QNNID  I  SECT  I  ONAL  INTENSITY  ON  ARlRTOUt 

•»|T| ' IARInT, B«S#>  ONNIDB, OHNJ 
RETuRH  TO  R|AB  NC»T  SET  OF  CARB  INAuT 


CO  TO  IB 

C  IIRIRIItlSItlllt 

C 

C  lIBRIiiSatiiilii 

C 

RSlR  rORNATif lf.4. 


INAuT  FORNATS 


.  LI  • 


InAuT-CuTAjT  FORNATS 


FORMAT (RRA4  ) 


OuTAuT  FORNATS 


•RRR  F ORNAT (//.IBM, JSNHORNAL  TERN|NAT|ON  OF  CNR I BE  > 

MBA  FORMAT  I  IN  j ,  |B*.  JRmBNIA  NOISE  RUN  *.  BM4,  in*.  /// 
BROS  FORMAT  I INR,  3|nTh£  fNIA  COuhT  FILE  IS  IKnTifIEB  l» 


I 


IN 


2RA4, 


ft. 

3  Ml. 

4  31* 

BfiR?  rORMATti nr. 
SB  IB  FORMAT i I  MR. 


< DECREES  i 


9MTMCRC  are.  13.  9H  SECTORS) 

3RMSEC TOR  NUMBER  AnII  TO  AN I 2 

13.  3*.  ar it.  j  i 

2RHSMIA  SOURCE  LEulL  JJ,  F7 2.  *h  0#.  j 

4SM  THE  TRANSMISSION  LOSS  FILE  IS  IDENTIFIED  IV  • 

1  . 2RA4 .  in*,  //. 

2  23H  THERE  IS  a  RCCEIUER  AT.  fu  2.  2Rh  FT  .  a  FRCOuCNCy  OF. 

3  F| |. 2.  3BH  HZ.,  AND  •  RANGE  INCREMENT  Of.  FR ■ 2, 

4  ISM  NAUTICAL  HJLES.  > 

9615  FORMAT i  INR.  4?hTmC  TRANSMISSION  LOSS  OATA  FOR  A  UN I FOR A  FIELD  > 
9S2R  FORMAT (  |HR ,  ifik.  BhThERE  ARE .  IS.  S4NTRANSA I SS (ON  LOSS  VALUES  FR 
ION  SMIAAINC  SOURCE  DEATH  OF.  FB.2.  t|H  FT..  Out  TO.  FB-2, 

2  t  Snnaut I  CAL  RILES  . - 

3  17X.  4 TmT m£  F|RSt  UAL j|  IS  AT  RANGE  •  RANGE  INCREMENT  i.  »I  2, 

4  3SMNR.  ).  TmEn  AROCEID  ALONG  EACH  LINE). 

5  (SI  .  1SFR.I  )> 

BS2S  f ORNAT (  )M|.  DhSCTOI  nuN||R.  13.  2h  i.  PCI.  4h  TO.  F(.l. 

1  23H  DECREES  HAS  A  total  OF.  FR  2.  Rh  ShJAS  |h.  13. 

2  l BN  scctor-aance  bins 

VS  JR  FORMAT.  |H#  I 

BS3S  FORMAT (  I Tl  ,  IShSIC TOR- RANGE  II*  13.  2h  i.  FR.2.  3h  TO,  FB.2, 

1  BMMH.  .  MAS.  FB.2  .  ISh  $m[AS.  hoISC  IS.  F|R.4. 

2  2RH  BB  WITH  INTENSITY  . .  Ell  4> 

M«R  F  ORNAT  i  INR.  j  BMP  OR  SECTOR.  13.  17m.  SECTOR  NOISE  IS,  FlR.4, 

I  #RM  BB  WITN  INTENSITY  .  .  Cl  1.4,  I 

B44S  FORMAT (  |H|,  Six .  HhsICtOR  INFORMATION./, 

I  1)1.  IBM . .//, 

•  1(1.  SBMfCCTOR  NURBCR  And  *0  AhIC  ( OECRCES  )  SNIAS  NO  If 

)fc  (DB)  |NT|hS:*v.  •  - 

4  Jll.  (3.  1«.  IFlB.l.  fifc  2.  FU  4.  £13. 4  ) 

BSSt  FORMAT f  Ihi,  Jill).  ),  ]ZM.  TJU"D.  /. 

1  321.  INI.  7t«.  | N I , 

2  IBM.  3RMB  Th|  OMNIDIRECTIONAL  NOISE  IS.  FlR.4, 

3  2RM  DI  yITh  Intensity  Ill  4.  2h  I. 

4  32*. 


32m 


73. 
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IHPCB  MESSAGES 


>*.R  FORNaTUhR.  1  2RhT  .  i  ’RANSAJ5S10N  LOSS  FILE.  1  ’L .  HAS  0*TA  THAT  DOE 
IS  NOT  COuIR  ThE  SANE  number  or  SECTORS  DCFJMD  FOR  ThIS  SMIA  NOISE 
2RuN.  ) 


9R3R  FORMAT  IhR. 
IMIS  Run. 


9I7R  FORNA*. 

C 

BIRR  FORMAT. 


5Iy’h(  ’BAN**!, SION  less  FUC.  111.  HAS  NO  DATA  FOR  T 

«■»*•*"*  UEO" lT*'  ANI  SHJA  COUNT  rite.  ISnIAS,  NAS  NO  D 
Bun  .  i 

36h-h|BE  IS  MO  TITLE  CABO  FOR  THIS  RUN.) 

Ox.  «6-  --  AtQCRAA  CNCISE  ABORTED  In  NAIN  AROCRAN-- 


SUBROUTINE  AARSUNIKLR.RI  .Til. R2. TLB. SINT  I 
C 

C  It  AURAOSC  -THIS  SUBROUTINE  EVALUATES  TNC  INTEGRAL  OF 
C  SR  LAMBDA (R  )| IRIK (SRC-TL »/|(>  OVER  A  SINGLE 

C  It  BE  GHENT  OF  RANK  .DCLR.  RUNNING  FROM  RANK  Rl 

C  RB  TO  RANGE  R2.  MERE  lAARDAlR  I  IS  MFINEB  IN 

C  *•  AROGRAR  CNOISE  The  TRaNSNISSIOH  LOSS  IS 

C  SB  ASSURED  TO  BE  LINEAR  OUCR  KLR. 


II 

tl 

•  I 
II 

•  I 


AAA ARC  TER 
Dili 


TL* 

SRC 

SINT 


TVAE 

INAUT 

INAUT 

INAUT 

INAUT 

INAUT 

INAUT 

OUTAUT 


KBCRIATION 

-RANK  INTERAL  (IN  NR)  OF  WHICH 
INTEGRAL  IB  EVALUATED 
•INITIAL  RANGE  (MN1  OF  INTERVAL 
•TRANBRIBSIOM  LOBS < IN  DB (AT  A| 
-FINAL  RANK  <  NR  I  OF  INTERVAL 
- TRANRN I BB I ON  LOSB<IN  DB I  AT 
-SNIA  SOURCE  LEVEL  «1N  BB > 
-VALUE  OF  INTEGRAL  > INTINSITV t 


COMMON  /AMTSR/  AL Aha,  C  .  SRC 


El  -  0. Ill SRC-TL  I  I 
B  •  UE-Ui 


CHECK  TO  A  FLAT  TL  CURVE  SEGMENT 
IT.  R.Bii  »  CO  TO  IBB 


IF  (ABS(B) 
B  -M-1B.B 
SINT  .SINT 


i DCLR'B  > 

Al Aha  IBS i (R2-R >lCxA( ( $RC -TL2  *IB. IRC  » 
- (Rl -B  llExA l Clt 1 >  1 


CO  TO  BRR 


C 

IBB  CONTINUE 
C 

C  It  EVALUATE  INTEGRAL  FOR  fACCIAL  CASE  WHEN  T(Jl*T<j«it 
C 

BINT  .  SINT  *ALAHA|<  ( IB.0IKC1  I  >/2.  lliRtRRI-RISRl  > 

C 

9GR  RETURN 
CNR 


NOT  REPRODUCIBLE 
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13.  Conclusion 

This  document  has  addressed  th  c 

of  programming  style.  Its  ap  . .on 

will  certainly  require  more  work,  for 
the  programmer  in  the  short  term,  but 
in  the  long  term,  the  rewards  to  the 
programmer,  his  organization,  and  other 
organizat i ons  and  individuals  using  the 
programs  could  be  substantial.  The 
programmer  should  gain  in  the  long 
term,  because  hts  programs  will  be 
easier  tor  him  t o  understand,  and  will 
be  more  likely  t>  be  used  by  others. 

The  organization  will  gain  because  the 
costs  it  incurs  lor  maintenance  and 
software  conversion  will  be  lower. 

Other  individuals  and  organizations 
will  profit  because  less  effort  will  be 
required  to  understand,  use,  extend, 
and  adapt  the  pr ograms. 
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Appendix  A.  Fortran  Keywords 


The  following  is  a  list  of  FORTRAN 
keywords  and  other  character  strings 
that  should  be  avoided  when  naming 
quantities  such  as  variables,  programs, 
subroutines  and  arrays: 


ACCESS 

AND 

ARRAYS 

ASSIGN 

BACKSPACE 

BLANK 

BLOCK 

BUFFER 

CALL 

CHARACTER 

CLOSE 

CLOSEM 

CLOSMS 

COMMON 

COMPLEX 

CONTINUE 

data 

DATE 

DECODE 

DIMENSION 

DO 

DOUBLE 

DUMP 

ELSE 

ENCODE 

END 

ENDFILE 

ENTRY 

EOF 

EQ 

EQUIVALENCE 

ERR 

ERRSET 

EXIST 

EXIT 

EXTERNAL 


FALSE 

FILE 

FMT 

FORM 

FORMAT 

FORMATTED 

FUNCTION 

GE 

GET 

GOTO 

GT 

IF 

IMPLICIT 

INQUIRE 

INTEGER 

INTRINSICS 

LABEL 

LOGICAL 

LT 


MAXREC 

NAME 

NAMED 

NAMELIST 

NE 

NEXTREC 

NOT 

NUMBER 

OPEN 

OPENED 

OPENM 

OPENMS 

OR 

OVERLAY 


PARAMETER 

PAUSE 

PDUMP 

PLOT 

PRECISION 

PRINT 

PROGRAM 

PUNCH 

PUT 

READ 

READMS 

READEC 

REAL 

REC 

RECL 

RECOVR 

REMARK 

RETURN 

RETURNS 

REWIND 

SAVE 

STATUS 

STOP 

SUBROUTINE 

SYMBOL 

TAPE 

THEN 

TIME 

TRACE 

TRUE 

TYPE 

UNFORMATTED 

UNIT 

WEOR 

WRITE 

WRITEC 

WRITMS 
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Appendix  B.  Basic  External  Functions 


(From  ANSI  Standard  X3 . 9-1966) 

Number 

Type 

of  : 

Basic  Externa i  Function 

of 

Symbolic 

Def inition 

Arguments 

Name 

Argument 

Function 

Exponent lal 

ea 

i 

EXP 

Real 

Real 

i 

DEXP 

Double 

Double 

i 

CEXP 

Complex 

Complex 

Natural  Logarithm 

i°ge(a> 

i 

ALOG 

Real 

Real 

i 

DLOC 

Double 

Double 

i 

CLOG 

Complex 

Complex 

Common  Logarithm 

logio(a) 

1 

ALOG 10 

Real 

Real 

DLOGIO 

Double 

Double 

Tr igonomet r i c  Sine 

sin(a) 

i 

SIN 

Real 

Real 

1 

DS  IN 

Double 

Double 

i 

CSIN 

Complex 

Complex 

Trigonometric  Cosine 

cos(a) 

i 

COS 

Real 

Real 

i 

DCOS 

Double 

Double 

i 

CCOS 

Complex 

Complex 

Hyperbolic  Tangent 

tanh(a) 

i 

TANH 

Real 

Real 

Square  Root 

(a)02 

i 

SORT 

Real 

Real 

i 

DSQRT 

Double 

Double 

i 

CSQRT 

Complex 

Complex 

Arctangent 

arctan(a) 

i 

ATAN 

Real 

Real 

i 

DATAN 

Double 

Double 

arctanlaj/az) 

2 

ATAN2 

Real 

Real 

2 

DATAN2 

Double 

Double 

Remaindering 

aj(mod  a2> 

2 

DMOD 

Double 

Double 

Modulus 

1 

CABS 

Complex 

Real 

*The  function  DMOD  (aj,  a 2 )  Is  defined  as  aj-  [a^/a?]  a2,  where  [x]  is  the  Integer  whose  magnitude  does  not 
exceed  the  magnitude  of  x  and  whose  sign  Is  the  same  as  the  sign  of  x> 
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Appendix  C.  Basic  Intrinsic  Functions 


(From  ANSI 

Standard  X3 

I.9-196B) 

Intrinsic  Function 

Definition 

Number 

of 

Arguments 

Symbolic 

Name 

Type 

Argument 

of  : 

Function 

Absolute  Value 

hi 

1 

ABS 

IABS 

DABS 

Real 

Integer 

Double 

Real 

Integer 

Double 

Truncation  Sign 

of  a  times  largest  integer  < 

|a|  1 

AINT 

I  NT 

I  DINT 

Real 

Real 

Double 

Rea  1 

Integer 

Integer 

Remaindering* 

ajCmod  a2) 

2 

AMoD 

MOD 

Real 

Integer 

Real 

Integer 

Choosing  Largest 

Va  lue 

Min  (alt  a2,  ...) 

>2 

AMAXO 

AMAX1 

MAXO 

MAXI 

DMAX1 

Integer 

Real 

Integer 

Real 

Double 

Real 

Real 

Integer 

Integer 

Double 

Choosing  Smallest 
Value 

Min  (alt  a2> .. •) 

>2 

AMINO 

AMINI 

MI  NO 

MINI 

Integer 

Real 

Integer 

Double 

Real 

Real 

Integer 

Double 

F  loat 

Conversion  from  integer  to  real 

1 

FLOAT 

Integer 

Real 

Fix 

Converalon  from  real  to  Integer 

1 

IFIX 

Real 

Integer 

Transfer  of  Sign 

Sign  of  a2  times  |*2 | 

2 

SIGN 

ISIGN 

DSICN 

Real 

Integer 

Double 

Real 

Integer 

Double 

Positive 

Difference 

ai  -  Min  (ai,  a2) 

2 

DIM 

IDIM 

Real 

Integer 

Real 

Integer 

Obtain  Most 
Significant  Part 
of  Double 

Precision  Argument 

l 

SNGL 

Double 

Real 

Obtain  Real  Part 
of  Complex 

Argument 

1 

REAL 

Complex 

Real 

Obtain  Imaginary  Part 
of  Complex 

Argument 

l 

AIMAG 

Complex 

Real 

express  Single 
Precision  Argument 
In  Double 

Precision  Form 

1 

DBLE 

Real 

Double 

Express  Two  Real 
Arguments  in 
Complex  Form 

al  +  a2  "1 

2 

CMPLX 

Real 

Complex 

Obtain  Conjugate  of 
a  Complex 

Argument 

1 

CONJG 

Complex 

Corplex 

♦The  function  MOD  or  AMOD(ai.  a2)  defined  as  -  [«l/«2 J  a2  where  |x|  is  the  integer  whose  magnitude 
does  not  exceed  tut  magnitude  of  x  and  whose  sign  is  the  same  as  X. 


39 


Appendix  0.  Fortran  Structures  for  Emulating 
Structured  Programming  Constructs 


It  Is  generally  recognized  that  FORTRAN 
(X3. 9-1966)  is  not  a  good  language  for 
structured  programming  (Yourdon,  1975; 
Jensen,  1979).  Its  major  deficiencies 
are:  (1)  lack  of  block  structures,  as 

are  available  in  Languages  such  as 
Pascal  and  Algol;  (2)  lack  of  a  nested 
IF-THEN-ELSE  statement;  and  (3)  lack  of 
DO-WHILE  and  PERFORM-UNTIL  statements. 

Although  the  absence  of  these  state¬ 
ments  Increases  the  difficulty  of 
writing  structured  programs  in 
FORTRAN,  it  should  not  be  assumed  that 
one  cannot  write  structured  programs  in 
FORTRAN.  One  merely  has  to  write 
control  structures  corresponding  to 
those  advocated  by  structured 
programming  enthusiasts.  Interestingly 
enough,  however,  to  do  so  in  FORTRAN 
requires  the  use  of  the  GO  TO 
statement,  which  at  one  time  some 
structured  programming  enthusiasts  were 
considering  making  illegal.  Now  it  is 
generally  agreed  that  the  GO  TO 
statement  itself  is  not  bad,  but  rather 
its  uncontrolled  use.  One  cannot  be 
too  upset  with  the  original  FORTRAN 
designers,  because  the  language  was 
around  long  before  anyone  even  thought 
of  structured  programming.  Some  of  the 
deficiencies  of  FORTRAN  have  been 
recognized  and  have  been  corrected  in 
the  more  recent  version  of  FORTRAN 
(X3. 9-1978).  For  example,  the  revised 
language  now  includes  the  equivalent  of 
an  IF-THEN-ELSE  statement.  It  still 
does  not,  however,  include  a  DO-WHILE 
or  PERFORM-UNTIL  statement,  nor  does  it 
include  the  block  structure  concepts  of 
languages  such  as  ALGOL  and  PASCAL. 
Inclusion  of  the  latter  would  signifi¬ 


cantly  change  the  whole  design  of 
FORTRAN  and,  in  the  author’s  opinion, 
block  structure  unlikely  to  be  stand- 
ar  ized  in  FORTRAN  in  the  near  future. 
This  appendix  describes  the  logical 
control  structure  diagrams,  the 
equivalent  structured  programming 
pseudocode,  and  the  FORTRAN  code  for 
implementing  the  following  structured 
programming  constructs:  IF-THEN-ELSE, 
IF-ORIF-ELSE ,  CASE  (two  forms),  POSIT 
(two  forms),  DO-WHILE,  PERFORM-UNTIL, 
ESCAPE  and  CYCLE.  The  motivation  for 
these  constructs  is  described  in 
considerable  detail  in  Chapter  4  of 
Jensen  and  Tonies  excellent  book  on 
software  engineering  (Jensen,  1979). 

It  should  be  pointed  out  that  some  of 
the  above  forms  are  not  necessarily 
advocated  by  all  software  engineers. 

In  particular,  the  IF-ORIF-ELSE,  POSIT, 
ESCAPE  and  CYCLE  constructs  were  not 
described  in  Yourdon's  (1975)  book. 
Nevertheless,  Jensen  and  Tonies  present 
good  arguments  for  their  Inclusion  and 
thus  they  are  mentioned  here.  It 
should  also  be  pointed  out  that  we  have 
taken  the  liberty  of  adding  another 
construct,  the  PERFORM-UNTIL  (Form* 2). 
This  construct  is  equivalent  to  the 
traditional  FORTRAN  DO  loop,  which  is 
so  useful  for  indexing  arrays  and 
performing  other  counting  operations. 

It  was  included  here  because  the  author 
felt  it  was  unreasonable  to  request 
that  programmers  implement  their 
looping  operations  with  the  FORTRAN 
equivalent  code  PERFORM-UNTIL  (form  1), 
which  uses  the  GO  TO  and  IF  statemens, 
when  the  standard  FORTRAN  DO  loop  could 
in  many  cases  do  the  same  task  more 
concisely. 
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1.  SEQUENCE 

1.1  Logical  Control  Structure 


2.  IF-THEN-ELSE 

2.1  Logical  Control  Structure 


Figure  D-1 
Sequence  Structure 

1.2  Pseudocode 

CODE  A 
CODE  B 
CODE  C 

1 .3  FORTRAN  Implementation 

CODE  A 
CODE  B 
CODE  C 


Structure 


2.2  Pseudocode 

IF  (condition)  THEN 
CODE  A 

ELSE 

CODE  B 

ENDIF 

2.3  FORTRAN  Implementation 

IF  (condition)  GO  TO  a 
CODE  B 
GO  TO  c 
a  CONTINUE 
CODE  A 
c  CONTINUE 


3.0  IF-or-IF-ELSE 

3.1  Logical  Control  Structure 


Figure  D-3 
IF-OR-IF-ELSE 
Structure 
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3.2  Pseudocode 


4.2  Pseudocode 


IF  (condition  I) 

CODE  A 

ORIF  (condition  2) 

CODE  B 

ORIF  (condition  3) 

CODE  C 

ORIF  (condition  4) 

CODE  D 

ELSE 

CODE  E 

ENDIF 

3.3  FORTRAN  Implementation 

IF  (.NOT.  Condition  1)  GO  TO  a 
CODE  A 
GO  TO  e 
a  CONTINUE 

IF  (.NOT.  Condition  2)  GO  TO  b 
CODE  B 
GO  TO  e 
b  CONTINUE 

IF  (.NOT.  Condition  3)  GO  TO  c 
CODE  C 
GO  TO  e 
d  CONTINUE 

IF  (.NOT.  Condition  4)  GO  TO  d 
CODE  D 
CODE  E 
e  CONTINUE 

4.  CASE  Statement  -  (Form  1) 


4.1  Logical  Control  Structure 


CASE  OF  (index) 

CASE  (1) 

CODE  A 
CASE  (2) 

CODE  B 
CASE  (3) 

CODE  C 
CASE  (N) 

CODE  N 
CASE  ELSE 

CASE  E 
END  CASE 

4.3  FORTRAN  Implementation 


IF  (index  .LT.  1  .OR.  index 
.GT.  n)  GO  TO  e 

GO  TO  (a,  b,  c,  ...n),  index 
a  CONTINUE 
CODE  A 
GO  TO  g 
b  CONTINUE 
CODE  B 
GO  TO  g 
c  CONTINUE 
CODE  C 
GO  TO  g 


n  CONTINUE 
CODE  N 
GO  TO  g 
e  CONTINUE 
CODE  E 
g  CONTINUE 
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6.2  Pseudocode 
POSIT 

CODE  A 

QUIT  POSIT  IF  (Condition  1) 
CODE  B 

QUIT  POSIT  IF  (Condition  2) 
CODE  C 


POSIT  ELSE 
CODE  Z 
END  POSIT 

6.3  FORTRAN  Implementation 


CODE  A 


IF  (Condition 

1) 

GO 

TO 

a 

CODE  B 

IF  (Condition 

2) 

GO 

TO 

a 

CODE  C 

IF  (Condition 

3) 

GO 

TO 

a 

CODE  D 
GO  TO  b 
a  CONTINUE 
CODE  Z 
b  CONTINUE 
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7.  POSIT  -  (Form  2) 

7.1  Logical  Control  Structure 
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7.2  Pseudocode 


POSIT 

CODE  A 

IF  (Condition  1) 

CODE  XI 
QUIT  POSIT 
ENDIF 

CODE  B 

IF  (Condition  2) 

CODE  X2 
QUIT  POSIT 
ENDIF 

CODE  C 

IF  (Condition  3) 

CODE  X3 
QUIT  POSIT 
ENDIF 

CODE  D 
POSIT  ELSE 
CODE  Z 
END  POSIT 

7.3  FORTRAN  Implementation 
CODE  A 

IF  (.NOT.  Condition  1)  GO  TO  a 
CODE  XI 
GO  TO  z 
a  CONTINUE 
CODE  B 

IF  (.NOT.  Condition  2)  GO  TO  b 
CODE  X2 
GO  TO  z 
b  CONTINUE 
CODE  C 

IF  (.NOT.  Condition  3))  GO  TO  c 
CODE  X3 
GO  TO  z 
c  CONTINUE 
CODE  D 
GO  TO  d 
z  CONTINUE 
Code  Z 
d  CONTINUE 


8.  DO-WHILE 

8.1  Logical  Control  Structure 


Figure  D-8 
DO-WHILE  Structure 


8.2  Pseudocode 

WHILE  (condition) 

CODE  A 
END  WHILE 

8.3  FORTRAN  Implementation 
a  CONTINUE 

IF  (.NOT.  condition)  GO  TO  b 
CODE  A 
GO  TO  a 
b  CONTINUE 

An  alternative,  but  less  popular, 
implementation  which  has  the  advantage 
of  a  positive  test  on  the  predicate  Is 

GO  TO  a 
c  CONTINUE 

CODE  A 
a  CONTINUE 

IF  (condition)  GO  TO  c 
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9.  PERFORM-UNTIL  (Form  1) 

9.1  Logical  Control  Structure 


9.2  Pseudocode 

UNTIL  (condition) 

CODE  A 
END  UNTIL 

9.3  FORTRAN  Implementation 

a  CONTINUE 

CODE  A 

IF  (.NOT.  condition)  GO  TO  a 

An  alternative  implementation  which  has 
the  advantage  of  a  positive  test  on  the 
predicate  is: 


10.  PERFORM-UNTIL  (Form  2  -  DO  LOOP 
Equivalent) 

10.1  Logical  Control  Structure 


10.2  Pseudocode 
i-m^ 

UNTIL  (i  .GT.  m2) 
CODE  A 

i“i+ii>3 

END-UNTIL 

.10.3  FORTRAN  Implementation 

DO  a  i«m^ ,  m2 ,  m3 
CODE  A 
a  CONTINUE 

11.  ESCAPE 


GO  TO  b 
a  CONTINUE 

IF  (condition)  GO  TO  d 
b  CONTINUE 

CODE  A 
GO  TO  a 
d  CONTINUE 


The  ESCAPE  structure  is  an  uncondi¬ 
tional  branch  to  the  "outside"  of  its 
associated  structure.  If  the  exit  is 
from  an  iterative  loop,  the  branch 
would  be  to  the  outside  of  the  loop. 


This  provides  a  mechanism  for  an  easy 
exit  from  the  interior  of  a  set  of 
nested  iterative  loops. 


12.  CYCLE 


11.1  Logical  Control  Structure 


Example  of  an  escape  in  a 
DO-WHILE  structure,  The  code  B's 


Executed  at  the  time  of  the  escape 


Figure  D-11 
ESCAPE-Structure 


1 1 .2  Pseudocode  ( Example) 

S:  WHILE  (condition) 

CODE  A 

IF  (escape-condition) 

CODE  B 

ESCAPE  WHILE  S 
ENDIF 
CODE  D 
END  WHILE 

1 1 .3  FORTRAN  Implementation 

a  CONTINUE 

IF  (.NOT.  condition)  GO  TO  b 
CODE  A 

IF  (.NOT.  escape-condition)  GO  TO 
CODE  B 
GO  TO  b 
d  CONTINUE 
CODE  D 
GO  TO  a 
b  CONTINUE 


The  CYCLE  structure  is  an  unconditional 
branch  to  the  condition  controlling  the 
next  iteration,  i.e.  to  the  "inside”  of 
the  iteration  loop.  This  provides  a 
mechanism  for  easily  by-passing  code  in 
the  loop  to  advance  to  the  next 
iteration. 

12.1  Logical  Control  Structure 


Example  of  a  cycle  in  a  DO-WHILE 


12.2  Pseudocode 

C:  WHILE  (condition) 

CODE  A 

IF  (cycle  condition)  CYCLE  C 
CODE  B 
END  WHILE 

12.3  FORTRAN  Implementation 
a  CONTINUE 

IF  (.NOT.  condition)  GO  TO  b 
CODE  A 

IF  (cycle-condition)  GO  TO  a 
CODE  B 
GO  TO  a 
b  CONTINUE 


i  F*ei;docode 


S:  WHILE  (while  condition) 

CODE  A 

IF  (condition  2) 

CODE  B 

F SCAPE  WHILE  S 
END1F 

IF  (condition  3y 
CODE  C 
CYCLE  S 
ENDIF 
CODE  U 
END  WHILE  S 

3.3  FORTRAN  Implementation 

,•>  CONTINUE 

IF  (.NOT.  while  condition)  CO  TO  d 
CODE  A 

II  (.NOT.  condition  2)  GO  TO  e 
CODE  B 
.0  TO  d 
e  CONTINUE 

IF  (.NOT.  condition  3)  GO  TO  £ 
CODE  C 
GO  TO  a 
f  CONTINUE 

CODE  D 
GO  TO  a 
d  CONTINUE 
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